Backbone.js - nơi lưu trữ thông tin trạng thái?

Question

Tôi mới đến Backbone.js và tôi đang cố gắng tìm ra nơi các biến trạng thái phải hoạt động. Trường hợp sử dụng của tôi:

Tôi có một ứng dụng cung cấp giao diện đọc sách (tôi biết, ví dụ cổ điển, đúng không?). Mô hình của tôi là Book và Page với các lớp thu thập cho mỗi loại. Cấu trúc của ứng dụng sẽ gần như thế này (tha thứ cho Visio ASCII):

+------------+ 
| Controller | 
+------------+ 
    |  Views     Models 
    | +--------------+  +----------------+ 
    |-| IndexView |------| BookCollection | 
    | +--------------+  +----------------+ 
    |        | 
    | +--------------+  +----------------+ 
    +-| BookView |------|  Book  | 
     +--------------+  +----------------+ 
     |       | 
     | +--------------+   | 
     |-| TitleView |-+   | 
     | +--------------+ | +----------------+ 
     |     +-|  Page  | 
     | +--------------+ | +----------------+ 
     +-| PageView |-+ 
     +--------------+ 

Đó là, Controller instantiates và phối hai quan điểm, IndexView và BookView, được hỗ trợ bởi các mô hình. BookView instantiates và điều phối một tập hợp các subviews (thực sự có nhiều hơn hiển thị ở đây).

thông tin Nhà nước bao gồm:

• cuốn sách hiện tại (con trỏ hoặc id)
• trang hiện hành (con trỏ hoặc id)
• biến trạng thái UI khác, chẳng hạn như liệu hình ảnh trên trang có thể nhìn thấy hay không, cho dù các tiện ích khác đang mở hay đóng, v.v.

Câu hỏi của tôi là, thông tin trạng thái này nên ở đâu? tùy chọn có thể bao gồm:

• Các mô hình, mà có thể là nhà nước-aware. Điều này làm cho một số ý nghĩa, vì chúng được dự định để lưu trữ dữ liệu và quan điểm có thể lắng nghe những thay đổi trạng thái, nhưng nó không có vẻ như điều này phù hợp với mô hình Backbone.js dự định, và sẽ không luôn luôn có ý nghĩa (ví dụ như chuyển hình ảnh trên PageView sẽ áp dụng cho tất cả các trang, không chỉ áp dụng cho trang hiện tại)

• A mô hình singleton đặc biệt nhằm giữ thông tin trạng thái. Một lần nữa, làm cho tinh thần, dễ nghe, tất cả các quan điểm có thể liên kết với nó - nhưng một lần nữa, điều này có vẻ ngoài MVC tiêu chuẩn.

• Các xem, những người chịu trách nhiệm về tình trạng UI - nhưng điều này sẽ đòi hỏi quan điểm phải nhận thức được nhau để có được thông tin nhà nước, trong đó có vẻ không chính xác

• Các khiển, mà nên định tuyến ứng dụng giữa các tiểu bang - điều này có ý nghĩa, nhưng nó ngụ ý một chuyến đi khứ hồi hơi lẻ, ví dụ User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (chứ không phải đơn giản User selects "Show Images" --> View event listener is called --> View updates các)

Tôi đoán trong một số cách này là một MVC câu hỏi chung chung, nhưng tôi đang gặp sự cố khi nhận đầu tôi xung quanh nó. Phần nào của ứng dụng phải chịu trách nhiệm lưu trạng thái hiện tại?

CẬP NHẬT: Để tham khảo trong tương lai, tôi đã sử dụng mô hình đơn quốc gia toàn cầu cho vấn đề này.Dòng UI đi như thế này:

1. Xem UI handler làm gì, nhưng cập nhật app.State
2. router của tôi cũng không làm gì cả nhưng cập nhật app.State - chúng quan điểm cơ bản chuyên dụng hiển thị và phản ứng với URL thay đổi
3. xem nghe các thay đổi trên app.State và cập nhật tương ứng

Ứng dụng của tôi là Nguồn mở - bạn có thể xem code on Github. Đoạn liên quan ở đây là State model, mà tôi đã mở rộng để xử lý (de) trạng thái tuần tự hóa cho URL.

Answer 1

Tại sao không tạo mô hình trạng thái để lưu trữ và mô tả trạng thái hiện tại? Tôi không nghĩ điều đó là sai. Vì trạng thái hiện tại liên quan đến nhiều hơn một mô hình, tôi nghĩ nó hợp lý để tạo ra một mô hình trạng thái để lưu trữ và nhận trạng thái hiện tại.

Bộ điều khiển sau đó có thể giao tiếp với mô hình trạng thái để nhận trạng thái hiện tại. Trạng thái giao diện người dùng phải được lưu trữ trong mô hình tương ứng. Mô hình nhà nước biết cuốn sách nào và trang nào và sau đó là các mô hình sách và trang theo dõi trạng thái giao diện người dùng hiện tại của chúng.

Answer 2

Don't limit your Backbone apps to Backbone constructs. Nếu bạn thấy rằng ứng dụng của bạn cần một số chức năng không phù hợp với một trong các cấu trúc của Backbone, đừng làm nó trở thành một chức năng chỉ để giữ mọi thứ trong Backbone.

Tôi đã tìm thấy điều này backbone boilerplate để hữu ích về mặt này. Nó thiết lập các mô-đun cho bạn và cung cấp cho bạn một đối tượng ứng dụng mở rộng Backbone.Events (như trong bài báo được liên kết trước đó). Đối tượng ứng dụng này có thể được sử dụng để lưu trữ các mô hình, khung nhìn và bộ điều khiển/bộ định tuyến, và bạn sẽ cảm thấy tự do để thêm các mô-đun phi xương sống của riêng mình vào đối tượng ứng dụng, để xử lý các trách nhiệm không hoàn toàn phù hợp với một trong các Cấu trúc xương sống.