Bộ điều khiển nên biết về View & Model? hoặc ngược lại?


13

Về mặt khái niệm tôi đang cố gắng để hiểu nếu tôi nên làm điều này:

item = Model()
screen = View()
brain = Controller(item, screen)

hoặc cái này ..

brain = Controller()
item = Model(brain)
screen = View(brain)

hoặc cái này ..

class Controller():
    def __init__(self):
        item = Model(self)
        screen = View(self)

hoặc cái gì khác hoàn toàn?

Câu trả lời:


18

Đối với tôi, lựa chọn đầu tiên có ý nghĩa. Công việc của Bộ điều khiển là phối hợp giữa khung nhìn và mô hình. Từ quan điểm đó, điều hợp lý là bộ điều khiển là bộ điều khiển tham chiếu đến khung nhìn và mô hình.

Bạn thực sự không thể có bộ điều khiển mà không có Model và View, tuy nhiên sẽ rất có ý nghĩa khi chỉ có View hoặc chỉ có Model (ví dụ: trong thử nghiệm đơn vị). Đó là lý do tại sao bạn muốn chuyển những phần phụ thuộc đó vào Bộ điều khiển chứ không phải hai phần còn lại.


9

Các ModelViewđộc lập với nhau.

Đừng nghĩ của Controllernhư bộ não của cấu trúc MVC. Hãy nghĩ về nó như là người điều phối xử lý các yêu cầu từ trình duyệt và gửi chúng đến Model. Sau đó, nó lấy dữ liệu từ Modelvà đóng gói theo cách thân thiện với mẫu , sau đó gửi nó đến a View.

Đây Modelbộ não trong cấu trúc MVC và đây là lúc bạn nên đặt quy tắc kinh doanh của mình. Quy tắc kinh doanh là phổ biến trên nhiều bộ điều khiển . Vì vậy, bộ điều khiển tài liệu và bộ điều khiển báo cáo có thể sử dụng cả mô hình Người dùng để xem ai có quyền truy cập vào những thứ đó. Bạn sẽ không muốn lặp lại các quy tắc đó trong cả hai bộ điều khiển.

Các Viewnên sử dụng một mẫu HTML để trình bày dữ liệu trong một cụ thể cách không nguồn dữ liệu. Nó không nên bị ràng buộc chặt chẽ với lược đồ của cơ sở dữ liệu của bạn. Để hiển thị tiêu đề của tài liệu, bạn sẽ có chế độ xem đầu ra nội dung của biến mẫu được gọi document_titlevà chỉ Controllerbiết biến đó được đặt như thế nào và chỉ Modelbiết tại sao tài liệu đó có tiêu đề đó.


1
Tôi thích câu trả lời của bạn vì nó phù hợp với sự hiểu biết chung của tôi về MVC. Tuy nhiên, nó không giải quyết được một phần quan trọng của câu hỏi, cụ thể là phần nào của Bộ ba giữ tài liệu tham khảo cho những người khác? Sự nhầm lẫn mà tôi nghĩ xuất phát từ thực tế là những gì bạn mô tả, đó là Chế độ xem là "các mẫu câm có lỗ" (nghĩa là không có tham chiếu đến Bộ điều khiển, nhưng Bộ điều khiển biết các Chế độ xem và cắm dữ liệu từ Mô hình vào chúng). Đồng thời, một điều phổ biến khác mà tôi vẫn thấy là Chế độ xem sẽ gửi hành động của người dùng đến Bộ điều khiển. Làm thế nào Lượt xem có thể làm điều này mà không có tham chiếu đến C?
alnafie

@alnafie Bạn đã đơn giản hóa khung MVC thành 3 lớp. Hãy nhìn xung quanh các khung mã nguồn mở MVC hiện có và bạn sẽ thấy có nhiều yêu cầu hơn để làm cho nó hoạt động. Phải có một cái gì đó cao hơn để quản lý tất cả các phần cho khung. Một cái gì đó gọi Bộ điều khiển và một cái gì đó xử lý định tuyến đến các hành động trong Chế độ xem.
Phản ứng

3

MVC ban đầu được định nghĩa để dễ dàng lập trình các ứng dụng máy tính để bàn. Chế độ xem đăng ký các sự kiện mô hình, cập nhật bản trình bày khi mô hình thay đổi. Bộ điều khiển chỉ đơn thuần dịch các sự kiện giao diện người dùng (ví dụ: nhấn nút) thành các cuộc gọi đến mô hình. Vì vậy, bộ điều khiển và khung nhìn phụ thuộc vào mô hình, nhưng độc lập với nhau. Mô hình là độc lập của cả hai. Điều này cho phép nhiều khung nhìn và bộ điều khiển hoạt động trên cùng một mô hình.

Kiến trúc "MVC" được sử dụng cho các ứng dụng web 1.0 (làm mới toàn trang, không có AJAX) có hơi khác. Một yêu cầu web được gửi đến một bộ điều khiển. Bộ điều khiển bằng cách nào đó sửa đổi trạng thái mô hình, sau đó gửi một hoặc nhiều mô hình được hiển thị bằng một khung nhìn. Cả bộ điều khiển và khung nhìn đều phụ thuộc vào kiểu máy, nhưng bộ điều khiển cũng phụ thuộc vào khung nhìn.

Với các ứng dụng web 2.0, chúng tôi đang quay trở lại kiến ​​trúc MVC cổ điển, ở phía máy khách . Tất cả các mô hình, khung nhìn và bộ điều khiển đều nằm ở phía máy khách dưới dạng các đối tượng Javascript. Bộ điều khiển dịch các sự kiện của người dùng thành các hành động mô hình. Các hành động mô hình có thể hoặc không thể dẫn đến yêu cầu AJAX đến máy chủ. Một lần nữa, khung nhìn đăng ký vào các sự kiện mô hình và cập nhật bản trình bày tương ứng.


+1 câu trả lời hay. Tôi có thể hiểu các cuộc gọi lại mô hình cho các ứng dụng máy tính để bàn theo nghĩa cổ điển. Nhắc tôi về MFC cũ từ Microsoft.
Phản ứng

2

Chế độ xem nên đăng ký thay đổi trong mô hình. Có độ trễ trong sự phong phú của các đăng ký vì chúng có thể được chi tiết (hiển thị cho tôi các thay đổi hàng tồn kho cho mặt hàng cụ thể này) hoặc chung chung (mô hình đã thay đổi); Chế độ xem có thể truy vấn mô hình để phản hồi thông báo thay đổi. Khung nhìn thể hiện tập hợp các yếu tố mô hình mong muốn trên màn hình, cập nhật màn hình như khi xử lý các thông báo thay đổi.

Bộ điều khiển sẽ đẩy các thay đổi vào mô hình, là kết quả của hướng người dùng (ví dụ: lệnh bàn phím, chuột và menu).

Mô hình duy trì mô hình và một danh sách các đăng ký và sẽ thông báo cho các quan điểm về các thay đổi có thể áp dụng thông qua các đăng ký của họ.

Cũng cần có một cơ chế để tạo các khung nhìn và bộ điều khiển mới (vì trong MVC bạn sẽ có thể có hai hoặc nhiều khung nhìn của cùng một mô hình (chúng có thể là cùng một khung nhìn (điểm) hoặc các góc nhìn (điểm) khác nhau). Về mặt logic, chúng ta có thể xem xét rằng bộ điều khiển cần thực hiện hoặc có quyền truy cập vào một nhà máy view & bộ điều khiển (cặp), có thể là một phần của bộ điều khiển hoặc thành phần khác.


-1 Modelskhông thông báo Views. Controllerstruy vấn các Modelthay đổi, và sau đó kết xuất Viewsđể trình bày những thay đổi đó.
Phản ứng

4
@MathewFoscarini trong MVC, View đăng ký các thay đổi từ Model. Xem, ví dụ, wiki.squeak.org/squeak/598 .

Tôi nghĩ rằng chúng ta không nói về sự khác biệt trong các khung MVC hiện có. Zend MVC, C # .NET và CakePHP không kết nối Mô hình với Chế độ xem. Một khung nhìn trong các khung đó là độc lập. Tôi không biết MVC bạn đã làm việc với cái gì, nhưng tôi gọi nó là phi truyền thống.
Phản ứng

6
@MathewFoscarini: đó là tất cả các khung web và mặc dù chúng tự gọi là "MVC", chúng không tuân theo kiến ​​trúc MVC cổ điển.
kevin cline

2
Tôi không chắc bất kỳ MVC nào "truyền thống" hơn Smalltalk MVC, với nó là mô hình đầu tiên được mô tả.

1

MVC giống như một mô hình mô đun. Mục đích của nó là bất cứ khi nào bạn muốn thay đổi bố cục giao diện người dùng (chế độ xem), bạn không phải thay đổi logic ứng dụng (bộ điều khiển) hoặc xử lý dữ liệu nội bộ (mô hình).

Để đạt được điều này, mẫu là cách ly logic triển khai của từng thành phần MVC. Tuy nhiên, điều hoàn toàn bình thường là có các thành phần biết giao diện của nhau .

Những gì tôi thường thấy là bộ điều khiển tạo hoặc gọi mô hình và khung nhìn (do đó nó biết giao diện của chúng) và mô hình hoặc khung nhìn có thể thông báo cho bộ điều khiển đổi lại (giống như mẫu gọi lại hoặc mẫu quan sát). Phần quan trọng là bộ điều khiển không nhận thức được cấu trúc bố trí.

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.