Là 'C' trong MVC có thực sự cần thiết?

Tôi hiểu vai trò của mô hình và khung nhìn trong mẫu Model-View-Controller, nhưng tôi có một thời gian khó hiểu tại sao một bộ điều khiển là cần thiết.

Giả sử chúng ta đang tạo một chương trình cờ bằng cách sử dụng phương pháp MVC; trạng thái trò chơi phải là mô hình và GUI phải là dạng xem. Chính xác thì bộ điều khiển trong trường hợp này là gì?

Có phải nó chỉ là một lớp riêng biệt có tất cả các hàm sẽ được gọi khi bạn nói, nhấp vào một ô? Tại sao không chỉ thực hiện tất cả logic trên mô hình trong chế độ xem?

Sử dụng ví dụ của bạn, Người kiểm soát sẽ là người quyết định thế nào là một động thái hợp pháp hay không. Bộ điều khiển sẽ cho chế độ xem biết cách sắp xếp các mảnh trên bảng khi khởi động bằng cách sử dụng thông tin mà nó nhận được từ Mô hình. Có nhiều điều có thể được Bộ điều khiển xử lý nhưng điều quan trọng là suy nghĩ về Logic nghiệp vụ trên lớp đó.

Đôi khi tất cả các Trình điều khiển thực hiện là truyền thông tin qua lại, như trang đăng ký. Mặt khác, Bộ điều khiển là phần khó khăn của sự phát triển vì có nhiều việc cần phải thực hiện ở lớp đó như thi hành các quy tắc hoặc làm toán phức tạp chẳng hạn. Đừng quên Trình điều khiển!

Tại sao không chỉ thực hiện tất cả logic trên mô hình trong chế độ xem?

Bộ điều khiển là chất keo kết dính mô hình và xem với nhau, và nó cũng là lớp cách nhiệt giúp chúng tách rời nhau. Mô hình không nên biết bất cứ điều gì về chế độ xem và ngược lại (ít nhất là trong phiên bản MVC của Apple). Bộ điều khiển hoạt động như một bộ chuyển đổi hai chiều, dịch các hành động của người dùng từ chế độ xem thành tin nhắn sang mô hình và định cấu hình chế độ xem với dữ liệu từ mô hình.

Sử dụng bộ điều khiển để phân tách mô hình và khung nhìn làm cho mã của bạn có thể tái sử dụng nhiều hơn, dễ kiểm tra hơn và linh hoạt hơn. Hãy xem xét ví dụ cờ vua của bạn. Mô hình tất nhiên sẽ bao gồm trạng thái trò chơi, nhưng nó cũng có thể chứa logic ảnh hưởng đến các thay đổi đối với trạng thái trò chơi, chẳng hạn như xác định xem một động thái có hợp pháp hay không và quyết định khi trò chơi kết thúc. Khung nhìn hiển thị một bàn cờ và quân cờ và gửi tin nhắn khi một quân cờ di chuyển, nhưng nó không biết gì về ý nghĩa đằng sau các quân cờ, cách mỗi quân cờ di chuyển, v.v. Bộ điều khiển biết về cả mô hình và khung nhìn cũng như dòng chảy tổng thể của chương trình. Khi người dùng nhấn nút 'trò chơi mới', đó là bộ điều khiển cho người mẫu biết tạo trò chơi và sử dụng trạng thái của trò chơi mới để thiết lập bảng. Nếu người dùng di chuyển,

Nhìn vào những gì bạn nhận được bằng cách giữ mô hình và xem riêng biệt:

• Bạn có thể thay đổi mô hình hoặc khung nhìn mà không thay đổi mô hình khác. Bạn có thể phải cập nhật bộ điều khiển khi thay đổi một trong hai, nhưng theo một cách nào đó thì đây là một phần của lợi thế: các phần của chương trình có khả năng thay đổi nhiều nhất được tập trung trong bộ điều khiển.

• Mô hình và khung nhìn có thể được sử dụng lại. Ví dụ: bạn có thể sử dụng cùng một chế độ xem bàn cờ với nguồn cấp RSS làm mô hình để minh họa các trò chơi nổi tiếng. Hoặc, bạn có thể sử dụng cùng một mô hình và thay thế chế độ xem bằng giao diện dựa trên web.

• Thật dễ dàng để viết các bài kiểm tra cho cả mô hình và chế độ xem để đảm bảo rằng chúng hoạt động theo cách chúng cần.

• Cả mô hình và khung nhìn thường có thể tận dụng các phần tiêu chuẩn: mảng, bản đồ, bộ, chuỗi và các thùng chứa dữ liệu khác cho mô hình; các nút, điều khiển, trường văn bản, chế độ xem hình ảnh, bảng và các mục khác để xem.

Có rất nhiều, nhiều cách khác nhau để thực hiện mẫu thiết kế chung này, nhưng ý tưởng cơ bản là tách biệt các mối quan tâm khác nhau khi cần thiết. MVC là một sự trừu tượng tốt đẹp theo nghĩa:

Model : Đại diện cho dữ liệu đó, bất cứ điều gì có thể có nghĩa là
View : Đại diện cho giao diện người dùng, bất cứ điều gì có thể có nghĩa là
Bộ điều khiển : Đại diện cho chất keo khiến mô hình đó và chế độ xem tương tác, bất cứ điều gì có nghĩa là

Nó cực kỳ linh hoạt bởi vì nó không chỉ định rất nhiều. Rất nhiều người lãng phí rất nhiều băng thông để tranh luận chi tiết về ý nghĩa của từng yếu tố, tên nào nên được sử dụng thay cho tên này và liệu có thực sự nên có 3 hoặc 2 hoặc 4 hoặc 5 thành phần hay không, nhưng điều đó thiếu điểm mức độ nhất định.

Ý tưởng là tách ra các "khối" logic khác nhau để chúng không trùng nhau. Giữ các công cụ trình bày của bạn với nhau, giữ các công cụ dữ liệu của bạn với nhau, giữ các công cụ logic của bạn với nhau, giữ các công cụ giao tiếp của bạn với nhau. Và kể từ đó trở đi. Ở một mức độ nhất định, các lĩnh vực quan tâm này càng ít trùng lặp, thì càng dễ dàng thực hiện những điều thú vị với chúng.

Đó là tất cả những gì bạn thực sự nên lo lắng.

Tất cả các câu trả lời tốt cho đến nay. Hai xu của tôi là tôi thích nghĩ về bộ điều khiển chủ yếu được xây dựng với các câu hỏi như Cái gì và ở đâu?

• Tôi đã được hỏi nếu một quân cờ (xem) có thể được chuyển đến x. Được
  phép không? Tôi không chắc nhưng tôi biết ở đâu và hỏi ai (người mẫu).
• Một cái gì đó đã yêu cầu tôi lưu dữ liệu của tôi. Làm thế quái nào tôi làm điều đó? Tôi biết nơi để hỏi mặc dù! Làm thế nào chúng ta lưu dữ liệu hoặc nơi nó được lưu vào, tôi không biết, nhưng lớp Kho lưu trữ đó nên biết. Tôi sẽ chuyển tiếp nó và để nó giải quyết nó.
• Tôi đã phải hiển thị vị trí quân cờ hiện tại cho người dùng mà mô hình đã di chuyển nó đến. không chắc chắn nếu tôi muốn hiển thị các mảnh như màu xanh lá cây hoặc màu vàng? Bah, người quan tâm, tôi biết có một quan điểm có thể xử lý việc này vì vậy tôi sẽ chuyển cho họ dữ liệu và họ có thể quyết định cách thức hiển thị.

Những đoạn nhỏ này là những ví dụ về cách tôi cố gắng nhớ sự trừu tượng và khái niệm mà MVC đang cố gắng truyền tải. Ba quá trình suy nghĩ chính của tôi là gì, ở đâu và như thế nào.

Cái gì và ở đâu => Bộ điều khiển Cách thức và thời gian => Mô hình và chế độ xem

Về bản chất, các hành động điều khiển của tôi có xu hướng nhỏ và gọn và khi đọc chúng có xu hướng trông đôi khi giống như một sự lãng phí thời gian. Khi kiểm tra chặt chẽ hơn, họ đóng vai trò là người phát tín hiệu giao thông, chuyển các yêu cầu khác nhau đến các công nhân chiếm dụng nhưng không tự mình thực hiện bất kỳ công việc thực tế nào.

Bộ điều khiển có thể giúp trừu tượng hóa các giao diện của cả Chế độ xem và Mô hình để chúng không phải biết trực tiếp về nhau. Càng ít đối tượng phải biết, nó càng trở nên dễ kiểm tra và đơn vị hơn.

Chẳng hạn, Model có thể đang chơi một phiên bản khác của chính nó thông qua một Trình điều khiển. Hoặc Bộ điều khiển được nối mạng có thể kết nối các đối tượng Lượt xem của hai người chơi với nhau. Hoặc nó có thể là một bài kiểm tra Turing mà không ai biết.

Nó thực sự phát huy tác dụng khi bạn làm việc với các trình xử lý sự kiện, nhưng bạn vẫn cần bộ điều khiển để xử lý các tương tác giữa khung nhìn và mô hình. Lý tưởng nhất là bạn không muốn khung nhìn biết bất cứ điều gì về mô hình. Hãy suy nghĩ về nó, bạn có muốn một jsp để thực hiện tất cả các cuộc gọi cơ sở dữ liệu trực tiếp? (Trừ khi đó là một cái gì đó giống như tra cứu đăng nhập.) Bạn muốn chế độ xem hiển thị dữ liệu và không có logic nghiệp vụ nào, trừ khi nó xem logic kết xuất, nhưng không phải là logic nghiệp vụ.

Trong GWT, bạn có được sự phân tách rõ ràng hơn với MVP. Không có logic kinh doanh nào (nếu nó được thực hiện đúng) trong chế độ xem. Người trình bày hoạt động như một bộ điều khiển và khung nhìn không có kiến ​​thức về mô hình. Dữ liệu mô hình chỉ đơn giản là được chuyển qua để xem.

Chế độ xem Tài liệu (nghĩa là chế độ xem mô hình) là mô hình chuẩn cho phần lớn các ứng dụng Windows được viết bằng MFC, do đó, nó phải hoạt động trong nhiều trường hợp.

Tôi hiểu vai trò của mô hình và khung nhìn trong mẫu Model-View-Controller, nhưng tôi có một thời gian khó hiểu tại sao một bộ điều khiển là cần thiết.

Bạn có chắc chắn về điều đó không? (Ít nhất là như mô tả ban đầu) Điểm của mô hình là mô hình miền. Chế độ xem được cho là hiển thị mô hình miền cho người dùng. Bộ điều khiển có nhiệm vụ ánh xạ đầu vào mức thấp sang mô hình mức cao. Theo như tôi có thể nói lý do là một cái gì đó dọc theo dòng: A) việc sử dụng SRP ở mức độ cao. B) Mô hình được coi là phần quan trọng của ứng dụng, vì vậy hãy giữ những thứ không quan trọng và thay đổi nhanh hơn khỏi nó. C) logic kinh doanh dễ kiểm tra (và có khả năng script).

Chỉ cần nghĩ rằng nếu bạn muốn làm cho chương trình Cờ vua của bạn có thể sử dụng được bởi người mù, hãy trao đổi chế độ xem cho phiên bản có thể nghe được và bộ điều khiển hoạt động với bàn phím. Giả sử bạn muốn thêm trò chơi qua thư, thêm bộ điều khiển chấp nhận văn bản. Phiên bản thuần của game? Một bộ điều khiển chấp nhận các lệnh từ một ổ cắm sẽ thực hiện công việc. Thêm một kết xuất 3d đẹp cho nó, một cái nhìn mới tuyệt vời. Không có mô hình thay đổi cần thiết Cờ vua vẫn là cờ vua.

Nếu bạn trộn đầu vào với biểu diễn mô hình thì bạn sẽ mất khả năng đó. Bỗng nhiên Tướng không phải là Cờ vua, đó là Cờ vua với một con chuột khác với Cờ vua với bàn phím hoặc kết nối mạng.

Tôi nghĩ rằng MVC là ngu ngốc, có thể trong các lĩnh vực cụ thể, nó hoạt động tốt nhưng cá nhân ngay cả các trang web tôi viết không phù hợp với mvc. Có một lý do tại sao bạn nghe thấy frontend, backend và không bao giờ kết thúc cơ sở dữ liệu hoặc cái gì đó khác-end

IMO cần có API (phụ trợ) và ứng dụng sử dụng API (frontend). Tôi đoán bạn có thể gọi yêu cầu GET là bộ điều khiển (chỉ đơn giản gọi api phụ trợ) và html xem nhưng tôi thường không nghe thấy mọi người nói về chế độ xem dưới dạng html thuần túy cũng như mô hình là API phụ trợ.

IMO mọi thứ phải là một API vững chắc. Trên thực tế, chúng không cần phải vững chắc (như trong sạch và được xây dựng tốt) nhưng các phần bên trong của nó nên được giữ riêng tư và ứng dụng / frontend / bên ngoài api không bao giờ nên nói kết nối cơ sở dữ liệu cũng như không thể thực hiện các truy vấn thô.

Bây giờ nếu mã / thiết kế của bạn liên quan đến keo tốt của nó. Nếu trong trò chơi cờ vua của bạn có một số đánh dấu bạn có thể chỉnh sửa để hiển thị GUI, gui sẽ thu thập các hợp đồng / đầu vào và gọi MovePiece (srcPocation, dstPostion) (có thể trả về bool hoặc enum để nói liệu đó có phải là một nước đi hợp lệ hay không ) và ok với tất cả logic trong mô hình thì chắc chắn gọi nó là MVC. Tuy nhiên, tôi vẫn sắp xếp mọi thứ theo các lớp và API và đảm bảo rằng không có lớp chìm bếp nào chạm vào mọi thứ (cũng như không có API nào phải biết về mọi thứ).

Hãy nghĩ về một trình duyệt hiển thị một trang web tĩnh. Mô hình là HTML. Chế độ xem là kết quả thực tế trên màn hình.

Bây giờ thêm một số JavaScript. Đó là Người điều khiển. Khi người dùng nhấp vào nút hoặc kéo thứ gì đó Sự kiện được gửi tới JavaScript, nó sẽ quyết định việc cần làm và thay đổi HTML (Model) bên dưới và trình duyệt / trình kết xuất hiển thị những thay đổi đó trên màn hình (Chế độ xem).

Có lẽ một nút khác được nhấp, sự kiện được gửi đến một số trình xử lý (Trình điều khiển) và nó có thể khiến yêu cầu thêm dữ liệu được gửi đến dịch vụ web. Kết quả sau đó được thêm vào HTML (Model).

Bộ điều khiển phản ứng với các sự kiện và điều khiển những gì có trong Model và do đó những gì có trên màn hình / Chế độ xem.

Lùi lại một chút, bạn có thể nghĩ toàn bộ trình duyệt là Chế độ xem và máy chủ là Trình điều khiển và dữ liệu là Mô hình. Khi người dùng nhấp vào nút trong trình duyệt, sự kiện được gửi đến máy chủ (Trình điều khiển), nó sẽ tập hợp các tài nguyên dưới dạng trang HTML (Model) và gửi lại cho trình duyệt để hiển thị (Xem)

Xuống máy chủ cho dù đó là asp, php hay java, 'code' (Trình điều khiển) nhận sự kiện nhấp và truy vấn cơ sở dữ liệu hoặc kho lưu trữ tài liệu (Model) và tạo HTML. Từ quan điểm máy chủ, kết quả của tất cả các hành động của nó là Chế độ xem (HTML) của kho dữ liệu cơ bản (Mô hình). Nhưng từ quan điểm của khách hàng, kết quả của yêu cầu của nó đối với máy chủ là Mô hình (HTML)

Ngay cả khi bạn làm lộn xộn JavaScript của mình trong HTML hoặc PHP trong HTML, thì Model, View, Controller vẫn tồn tại. Ngay cả khi bạn nghĩ về yêu cầu của mình đối với máy chủ và phản hồi từ máy chủ như một con đường hai chiều đơn giản, vẫn có Mô hình, Chế độ xem và Bộ điều khiển.

Theo kinh nghiệm của tôi, trong một chương trình gui mvc máy tính để bàn truyền thống, bộ điều khiển kết thúc được đưa vào xem. Hầu hết mọi người không dành thời gian để đưa ra một lớp điều khiển.

cuốn sách của nhóm bốn người nói:

Các mẫu thiết kế trong Smalltalk MVC

Bộ ba mô hình / Chế độ xem / Bộ điều khiển (MVC) [KP88] được sử dụng để xây dựng giao diện người dùng trong Smalltalk-80. Nhìn vào các mẫu thiết kế bên trong MVC sẽ giúp bạn thấy ý nghĩa của cụm từ "mẫu".

MVC bao gồm ba loại đối tượng. Model là đối tượng ứng dụng, View là phần trình bày màn hình của nó và Trình điều khiển xác định cách giao diện người dùng phản ứng với đầu vào của người dùng. Trước MVC, các thiết kế giao diện người dùng có xu hướng gộp các đối tượng này lại với nhau. MVC tách chúng ra để tăng tính linh hoạt và tái sử dụng.

MVC tách các khung nhìn và mô hình bằng cách thiết lập giao thức đăng ký / thông báo giữa chúng. Một khung nhìn phải đảm bảo rằng sự xuất hiện của nó phản ánh trạng thái của mô hình. Bất cứ khi nào dữ liệu của mô hình thay đổi, mô hình sẽ thông báo các khung nhìn phụ thuộc vào nó. Đáp lại, mỗi lượt xem có một cơ hội để tự cập nhật. Cách tiếp cận này cho phép bạn đính kèm nhiều khung nhìn vào một mô hình để cung cấp các bài thuyết trình khác nhau. Bạn cũng có thể tạo các khung nhìn mới cho một mô hình mà không cần viết lại nó.

Sơ đồ sau đây cho thấy một mô hình và ba khung nhìn. (Chúng tôi đã bỏ qua các bộ điều khiển để đơn giản.) Mô hình chứa một số giá trị dữ liệu và các khung nhìn xác định bảng tính, biểu đồ và biểu đồ hình tròn hiển thị các dữ liệu này theo nhiều cách khác nhau. Mô hình giao tiếp với các khung nhìn của nó khi các giá trị của nó thay đổi và các khung nhìn giao tiếp với mô hình để truy cập các giá trị này.

Lấy theo mệnh giá, ví dụ này phản ánh một thiết kế tách rời các khung nhìn từ các mô hình. Nhưng thiết kế có thể áp dụng cho một vấn đề chung hơn: tách các đối tượng để thay đổi thành một đối tượng có thể ảnh hưởng đến bất kỳ số lượng nào khác mà không yêu cầu đối tượng thay đổi phải biết chi tiết về các đối tượng khác. Thiết kế tổng quát hơn này được mô tả theo mẫu thiết kế của Observer (trang 293).

Một tính năng khác của MVC là các khung nhìn có thể được lồng vào nhau. Ví dụ: bảng điều khiển các nút có thể được triển khai dưới dạng chế độ xem phức tạp chứa các chế độ xem nút lồng nhau. Giao diện người dùng cho trình kiểm tra đối tượng có thể bao gồm các khung nhìn lồng nhau có thể được sử dụng lại trong trình gỡ lỗi. MVC hỗ trợ các khung nhìn lồng nhau với lớp CompositeView, một lớp con của View. Các đối tượng CompositeView hoạt động giống như các đối tượng View; một khung nhìn tổng hợp có thể được sử dụng ở bất cứ nơi nào một khung nhìn có thể được sử dụng, nhưng nó cũng chứa và quản lý các khung nhìn lồng nhau.

Một lần nữa, chúng ta có thể nghĩ về điều này như một thiết kế cho phép chúng ta đối xử với một khung nhìn tổng hợp giống như chúng ta đối xử với một trong các thành phần của nó. Nhưng thiết kế có thể áp dụng cho một vấn đề chung hơn, xảy ra bất cứ khi nào chúng ta muốn nhóm các đối tượng và coi nhóm như một đối tượng riêng lẻ. Thiết kế tổng quát hơn này được mô tả bằng mẫu thiết kế Composite (163). Nó cho phép bạn tạo một hệ thống phân cấp lớp trong đó một số lớp con xác định các đối tượng nguyên thủy (ví dụ: Nút) và các lớp khác định nghĩa các đối tượng hỗn hợp (CompositeView) để lắp ráp các nguyên thủy thành các đối tượng phức tạp hơn.

MVC cũng cho phép bạn thay đổi cách một khung nhìn phản ứng với đầu vào của người dùng mà không thay đổi cách trình bày trực quan của nó. Ví dụ, bạn có thể muốn thay đổi cách nó phản ứng với bàn phím hoặc sử dụng menu bật lên thay vì các phím lệnh. MVC đóng gói cơ chế phản hồi trong đối tượng Bộ điều khiển. Có một hệ thống phân cấp các bộ điều khiển, giúp dễ dàng tạo một bộ điều khiển mới dưới dạng một biến thể trên một bộ điều khiển hiện có.

Một khung nhìn sử dụng một thể hiện của lớp con Bộ điều khiển để thực hiện một chiến lược phản hồi cụ thể; để thực hiện một chiến lược khác, chỉ cần thay thế cá thể bằng một loại bộ điều khiển khác. Thậm chí có thể thay đổi bộ điều khiển của chế độ xem trong thời gian chạy để cho phép chế độ xem thay đổi cách nó phản ứng với đầu vào của người dùng. Ví dụ: một khung nhìn có thể bị vô hiệu hóa để nó không chấp nhận đầu vào chỉ bằng cách cung cấp cho nó một bộ điều khiển bỏ qua các sự kiện đầu vào.

Mối quan hệ Bộ điều khiển xem là một ví dụ về mẫu thiết kế Chiến lược (315). Chiến lược là một đối tượng đại diện cho một thuật toán. Nó hữu ích khi bạn muốn thay thế thuật toán tĩnh hoặc động, khi bạn có nhiều biến thể của thuật toán hoặc khi thuật toán có cấu trúc dữ liệu phức tạp mà bạn muốn gói gọn.

MVC sử dụng các mẫu thiết kế khác, chẳng hạn như Phương thức Factory (107) để chỉ định lớp trình điều khiển mặc định cho chế độ xem và Trình trang trí (175) để thêm cuộn vào chế độ xem. Nhưng các mối quan hệ chính trong MVC được đưa ra bởi các mẫu thiết kế của Observer, Composite và Strateg.