Kiến trúc của một ứng dụng web JavaScript một trang?


99

Một ứng dụng web JS một trang phức tạp nên được cấu trúc như thế nào ở phía máy khách? Cụ thể, tôi tò mò về cách cấu trúc ứng dụng rõ ràng về các đối tượng mô hình, thành phần giao diện người dùng, bất kỳ bộ điều khiển nào và các đối tượng xử lý tính bền vững của máy chủ.

Ban đầu, MVC có vẻ phù hợp. Nhưng với các thành phần giao diện người dùng được lồng ở các độ sâu khác nhau (mỗi thành phần có cách hoạt động / phản ứng riêng với dữ liệu mô hình và từng tạo ra các sự kiện mà bản thân chúng có thể xử lý trực tiếp hoặc không thể xử lý trực tiếp), có vẻ như MVC không thể được áp dụng một cách rõ ràng. (Nhưng hãy sửa tôi nếu không phải như vậy.)

-

( Câu hỏi này dẫn đến hai gợi ý về việc sử dụng ajax, điều này rõ ràng là cần thiết cho bất kỳ thứ gì khác ngoài ứng dụng một trang tầm thường nhất.)


Bạn có thể thử angleJS hoặc backboneJS
Romain

2
Bạn có thể cung cấp những hiểu biết của riêng bạn cho câu hỏi này? Đã lâu rồi kể từ khi bạn hỏi câu hỏi này và tôi muốn biết những khía cạnh quan trọng nhất mà bạn học được từ kinh nghiệm của chính mình với Javascript SPA.
Adrian Moisa

Câu trả lời:


35

Kiến trúc MVC của PureMVC / JS là IMO thanh lịch nhất. Tôi học được rất nhiều từ nó. Tôi cũng nhận thấy Kiến trúc ứng dụng JavaScript có thể mở rộng của Nicholas Zakas hữu ích trong việc nghiên cứu các tùy chọn kiến ​​trúc phía máy khách.

Hai mẹo khác

  1. Tôi nhận thấy quản lý chế độ xem, tiêu điểm và đầu vào là những lĩnh vực cần đặc biệt chú ý trong các ứng dụng web một trang
  2. Tôi cũng thấy hữu ích khi trừu tượng hóa thư viện JS, để mở cánh cửa để thay đổi suy nghĩ về những gì bạn sử dụng hoặc trộn & kết hợp nếu cần.

13

Bài thuyết trình của Nicholas Zakas như Dean đã chia sẻ là một nơi rất tốt để bắt đầu. Tôi cũng đã đấu tranh để trả lời câu hỏi tương tự trong một thời gian. Sau khi thực hiện một vài sản phẩm Javascript quy mô lớn, hãy nghĩ đến việc chia sẻ những kiến ​​thức học được như một kiến ​​trúc tham khảo trong trường hợp ai đó cần nó. Hãy xem:

http://boilerplatejs.org/

Nó giải quyết các mối quan tâm về phát triển Javascript phổ biến như:

  • Cấu trúc giải pháp
  • Tạo hệ thống phân cấp mô-đun phức tạp
  • Thành phần giao diện người dùng độc lập
  • Giao tiếp giữa các mô-đun dựa trên sự kiện
  • Định tuyến, Lịch sử, Đánh dấu trang
  • Kiểm tra đơn vị
  • Bản địa hóa
  • Tạo tài liệu

Vân vân.


10

Cách tôi xây dựng ứng dụng:

  • Khuôn khổ ExtJS, ứng dụng một trang, mọi thành phần được xác định trong một tệp JS riêng biệt, được tải theo yêu cầu
  • Mọi thành phần liên hệ với dịch vụ web chuyên dụng của riêng nó (đôi khi nhiều hơn một), tìm nạp dữ liệu vào các cửa hàng ExtJS hoặc cấu trúc dữ liệu cho mục đích đặc biệt
  • Kết xuất sử dụng các thành phần ExtJS tiêu chuẩn, vì vậy tôi có thể liên kết các cửa hàng với lưới, tải biểu mẫu từ bản ghi, ...

Chỉ cần chọn một khung javascript và làm theo các phương pháp hay nhất của nó. Mục yêu thích của tôi là ExtJS và GWT, nhưng YMMV.

KHÔNG sử dụng giải pháp của riêng bạn cho việc này. Nỗ lực cần thiết để sao chép những gì mà các khung javascript hiện đại làm là quá lớn. Việc thích nghi với một thứ hiện có luôn nhanh hơn là xây dựng tất cả từ đầu.


10
Question - What makes an application complex ? 

Trả lời - Việc sử dụng từ 'phức tạp' trong chính câu hỏi. Do đó, xu hướng phổ biến sẽ là tìm ra một giải pháp phức tạp ngay từ đầu.

Question - What does the word complex means ?

Trả lời - Bất cứ điều gì không rõ hoặc hiểu một phần. Ví dụ: Lý thuyết về Lực hấp dẫn ngay cả ngày nay đối với tôi là COMPLEX nhưng với Ngài Isaac Newton, người đã khám phá ra nó vào năm 1655 thì không.

Question - What tools can I use to deal with complexity ?

Trả lời - Hiểu biết và đơn giản.

Question - But I understand my application . Its still complex ?

Trả lời - Hãy suy nghĩ hai lần, bởi vì sự hiểu biết và sự phức tạp không cùng tồn tại. Nếu bạn hiểu một ứng dụng khổng lồ khổng lồ, tôi chắc chắn bạn sẽ đồng ý rằng nó không là gì khác ngoài sự tích hợp của các đơn vị nhỏ và đơn giản.

Question - Why all of the above philosophical discussion for a question on 
           Single Page Application (SAP)?

Trả lời - Bởi vì,

-> SPA không phải là một số loại công nghệ cốt lõi mới được phát minh mà chúng ta cần phải phát minh lại bánh xe cho rất nhiều thứ mà chúng ta đang làm trong phát triển ứng dụng.

-> Khái niệm của nó được thúc đẩy bởi nhu cầu về hiệu suất tốt hơn, tính khả dụng, khả năng mở rộng và khả năng bảo trì của các ứng dụng web.

-> Đây là một mẫu thiết kế khá mới được xác định, vì vậy việc hiểu SPA như một mẫu thiết kế sẽ giúp bạn đưa ra các quyết định sáng suốt về kiến ​​trúc của một SPA.

-> Ở cấp cơ sở, không có SPA nào là phức tạp, bởi vì sau khi hiểu nhu cầu của một ứng dụng và mô hình SPA, bạn sẽ nhận ra rằng bạn vẫn đang tạo một ứng dụng, giống như cách bạn đã làm trước đây với một số sửa đổi và sắp xếp lại trong cách tiếp cận phát triển.

Question - What about the use of Frameworks ?

Trả lời - Khung công tác là mã / giải pháp tấm lò hơi cho một số mẫu chung và được xác định chung, do đó chúng có thể loại bỏ tải x% (biến, dựa trên ứng dụng) từ quá trình phát triển ứng dụng nhưng sau đó không nên mong đợi nhiều về chúng, đặc biệt đối với và các ứng dụng ngày càng tăng. Luôn luôn là một trường hợp tốt để kiểm soát hoàn toàn cấu trúc và luồng ứng dụng của bạn, nhưng quan trọng nhất là mã cho nó. Không được có vùng xám hoặc đen trong mã ứng dụng.

Question - Can you suggest one of the many approaches to SPA architecture ?

Trả lời - Hãy nghĩ về khuôn khổ của riêng bạn dựa trên bản chất của ứng dụng của bạn. Phân loại các thành phần ứng dụng. Tìm kiếm một khung hiện có gần với khung dẫn xuất của bạn, nếu bạn tìm thấy nó thì hãy sử dụng nó, nếu bạn không tìm thấy nó thì tôi khuyên bạn nên tiếp tục với khung của bạn. Tạo khuôn khổ là một nỗ lực từ trước nhưng tạo ra kết quả tốt hơn về lâu dài. Một số thành phần cơ bản trong khuôn khổ SPA của tôi sẽ là:

  • Nguồn dữ liệu: Mô hình / Bộ sưu tập mô hình

  • Đánh dấu để trình bày dữ liệu: Mẫu

  • Tương tác với ứng dụng: Sự kiện

  • Chụp trạng thái và điều hướng: Định tuyến

  • Tiện ích, vật dụng và trình cắm thêm: thư viện

Hãy cho tôi biết nếu điều này giúp ích theo cách nào và chúc bạn may mắn với kiến ​​trúc SPA của bạn !!


1
Điều này bổ sung một số góc nhìn tuyệt vời (điều đó thường hiếm). Cám ơn!
Cody

4

Điều tốt nhất cần làm là xem xét cách sử dụng ví dụ của các khuôn khổ khác:

TodoMVC giới thiệu nhiều khuôn khổ SPA.



1

Ứng dụng web mà tôi hiện đang làm việc sử dụng JQuery và tôi sẽ không đề xuất nó cho bất kỳ ứng dụng web trang đơn lớn nào. Hầu hết các framework như Dojo, yahoo, google và những framework khác đều sử dụng không gian tên trong thư viện của họ nhưng JQuery thì không và đây là một nhược điểm đáng kể.

Nếu trang web của bạn có mục đích nhỏ thì JQuery sẽ ổn nhưng nếu bạn có ý định xây dựng một trang lớn thì tôi khuyên bạn nên xem xét tất cả các khung Javascript có sẵn và quyết định cái nào đáp ứng được nhu cầu của bạn nhất.

Và tôi khuyên bạn nên áp dụng mẫu MVC cho javascript / html của bạn và có lẽ hầu hết mô hình đối tượng của bạn cho javascript có thể được thực hiện dưới dạng json mà bạn thực sự trả về từ máy chủ thông qua ajax và javascirpt sử dụng json để hiển thị html.

Tôi khuyên bạn nên đọc cuốn sách Ajax đang hoạt động vì nó bao gồm hầu hết những điều bạn cần biết.


jQuery có thể được viết (giống như bất kỳ JS nào) theo cách không gian tên bằng cách sử dụng các nguyên mẫu. Tôi không chắc đó là một tính năng đủ lớn hoặc đủ ít người biết đến để đảm bảo trừu tượng hóa đằng sau một khuôn khổ - tôi thích tìm hiểu những gì JS thực sự đang làm. stackoverflow.com/questions/881515/…
SimplGy

4
JQuery không phải là một khung ứng dụng phía máy khách. Nó được nhắm mục tiêu ở một "cấp thấp hơn" hơn thế. JQuery được thiết kế để đơn giản hóa việc duyệt tài liệu HTML, xử lý sự kiện, hoạt ảnh và các hoạt động Ajax cũng như để loại bỏ sự khác biệt giữa các trình duyệt. Đối với các ứng dụng lớn hơn, bạn nên sử dụng khung ứng dụng phía máy khách như knockout hoặc backbone TRONG CHỨC NĂNG VỚI JQuery.
Sam Shiles

Vì vậy, quan điểm của tôi vẫn đúng nếu loại trực tiếp hoặc xương sống không bao gồm, duyệt tài liệu, xử lý sự kiện, v.v. thì không có giá trị nhiều. Khung ứng dụng YUI3 có và không cần JQuery nếu bạn sử dụng nó.
cơn bão tố

1
jquery giữ tất cả các phương thức của nó được lưu trữ trong biến jQuery và biến $. Nếu bạn sử dụng tùy chọn không có xung đột thì chỉ tên jQuery được tạo trong không gian tên chung. jQuery không phải là một khuôn khổ, chỉ là một thư viện, nó không cho bạn biết cách thực hiện mọi thứ, chỉ cung cấp một số phím tắt để thực hiện một số công việc phổ biến. So sánh jQuery với Dojo / YUI, v.v. là sai.
Hoffmann

1
@eaglestorm Câu lệnh if của bạn đánh giá sai.
John Lehmann




0

Thay thế: hãy xem ItsNat

Hãy suy nghĩ trong JavaScript nhưng mã giống nhau trong Java trong máy chủ có cùng API DOM, trong máy chủ là cách dễ dàng hơn để quản lý ứng dụng của bạn mà không cần máy khách / cầu nối tùy chỉnh vì giao diện người dùng và dữ liệu ở cùng nhau.



0

NikaFramework cho phép bạn tạo ứng dụng một trang. Đồng thời cho phép bạn viết HTML , CSS ( SASS ), JavaScript thành các tệp riêng biệt và cuối cùng gói chúng thành một tệp đầu ra.


0

Tôi muốn giới thiệu để khám phá Yeoman . Nó cho phép bạn sử dụng "phương pháp hay nhất" hiện có cho dự án mới của bạn.

Ví dụ:

nếu bạn quyết định sử dụng Angular.js, có một trình tạo Yeoman , cung cấp cho bạn cấu trúc định tuyến, chế độ xem, dịch vụ, v.v. Đồng thời cho phép bạn Kiểm tra, rút ​​gọn mã của mình, v.v.

Nếu bạn quyết định sử dụng Backbone, hãy xem trình tạo này

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.