MVC: tại sao chúng ta cần "điều khiển", hoặc khi nào chúng ta nên sử dụng mẫu này?

Question

Tôi đã đọc nhiều ấn bản về MVC, nhưng tôi vẫn chưa thể hiểu rõ tại sao chúng ta cần "bộ điều khiển".

Tôi thường viết các ứng dụng trong client-server mô hình:

máy chủ chứa tất cả các doanh nghiệp logic, và nó biết gì về gui. Nó thực hiện công việc chính, và nó càng di động càng tốt.

khách hàng là GUI, nó liên kết với máy chủ, tương tác với người dùng, gửi lệnh từ người dùng đến máy chủ .

Tôi thích kiến ​​trúc này, và tôi không thể hiểu tại sao người ta thực sự cần thêm một trung gian giữa client và máy chủ, mà dường như là khiển?

UPD: ví dụ đơn giản: giả sử chúng ta cần viết một số trình ghi dữ liệu. Dữ liệu đến từ cổng COM, nó được mã hóa bởi một số giao thức. Cần hiển thị các tin nhắn đã nhận trong cửa sổ nhật ký đơn giản.

Làm thế nào tôi có thể làm cho nó:

máy chủ chứa các mục sau đây:

• Data_receiver: thực sự nhận được dữ liệu thô từ cổng COM, nhưng đó là giao diện, vì vậy chúng tôi có thể làm cho một số một lớp khác nhận dữ liệu từ bất kỳ nguồn nào khác;
• Data_decoder: lấy dữ liệu thô và trả về các thư được giải mã kết quả, đó là giao diện, vì vậy chúng tôi có thể thay đổi giao thức mã hóa dễ dàng;
• Data_core: sử dụng các phiên bản Data_receiver và Data_decoder, phát ra tín hiệu cho khách hàng.

client chứa các mục sau đây:

• Appl lõi: tạo ra thể hiện của Data_receiver (một trong những kết nối với cổng COM), Data_decoder và Data_core (mất tài liệu tham khảo để Data_receiver và Data_decoder trường hợp) , cũng tạo GUI cửa sổ nhật ký đơn giản (có tham chiếu đến Data_core);
• GUI cửa sổ nhật ký đơn giản: liên kết với Data_core, tức là lắng nghe tín hiệu phát ra và hiển thị dữ liệu đã nhận.

Như tôi hiểu những gì tôi đã đọc về MVC, GUI nên không thực sự mất tin nhắn đã nhận từ Data_core, vì khiển nên làm điều đó và sau đó truyền dữ liệu cho GUI. Nhưng điều gì sẽ xảy ra nếu GUI lấy dữ liệu này trực tiếp từ mô hình ?

Answer 1

"client-server" không liên quan gì đến MVC, afaik.

tôi hiểu nó như thế này:

• Các Model là cách bạn cấu trúc dữ liệu của bạn.
• View là biểu diễn hiển thị. (GUI)
• Controller sử dụng logic để kiểm soát chế độ xem và/hoặc logic khác.

Ý tưởng đằng sau đó là tách biểu diễn trực quan khỏi logic. Vì vậy, khi bạn lấy View bạn không sao chép logic. ... vì vậy trong trường hợp của bạn, bạn có thể sử dụng MVC chỉ ở phía khách hàng và bạn cần một bộ điều khiển, bởi vì đó là nơi tất cả các phép thuật xảy ra.

Answer 2

Tôi nghĩ về mẫu MVVM khi đọc chi tiết về mẫu máy khách-máy chủ của bạn. Khi bạn muốn thực hiện các bài kiểm tra đơn vị, tốt hơn là xem VM (ViewModel) làm bộ điều khiển.

Theo mẫu của bạn, mẫu máy khách/máy chủ cổ điển, Trình điều khiển, Mô hình và Chế độ xem trực tiếp trong mã máy chủ mà bạn gọi là Data_receiver, Data_decoder và Data_core. Trong 'client' của bạn, bạn lại có một controller và view. Nó rất hữu ích để tách biệt với mã máy chủ mà một Controller nhận và giải mã tín hiệu và dữ liệu từ COM, một Mô hình mà Bộ điều khiển truyền và nhận dữ liệu trong đường đến và từ cơ sở dữ liệu, Chế độ xem mã hóa và định dạng dữ liệu thô từ Mô hình.

Theo nguyên tắc Không lặp lại (DRY), bạn có thể nhận thấy có mã bộ điều khiển trong cả phần máy chủ và phần máy khách của mã nơi bạn lặp lại mã hoặc trách nhiệm.

Điều này rất hữu ích khi bạn đang thúc đẩy sự phát triển của mình trong thời trang Phát triển thử nghiệm để phân tách thành các phần riêng biệt, sao cho bạn có thể đính kèm các bài kiểm tra khác nhau.

Answer 3

Tốt hơn bao giờ hết, tôi không muốn sửa sai giải thích "Tại sao cần thêm một lớp nữa giữa máy khách và máy chủ".

NẾU bạn đi qua các dòng sau, câu trả lời rõ ràng là MVC là mô hình tam giác của kiến ​​trúc.

Xem yêu cầu yêu cầu cho Mô hình, Mô hình yêu cầu Bộ điều khiển, Bộ điều khiển xử lý và gửi lại cho Chế độ xem.

The Model is the way you structure your data. 
The View is the visible representation. (GUI) 
The Controller uses the logic to control the view and/or other logic. 

Kính trọng, Pavan.G

Answer 4

Trong quá khứ tôi đã tự hỏi mình câu hỏi này tương tự nhiều lần và tôi gần đây đã được đọc về kiến ​​trúc mô hình JSP 2, và mục wikipedia nói sau.

Tài liệu về công nghệ cấp Web trong nền tảng J2EE thường sử dụng thuật ngữ "Mô hình 1" và "Mô hình 2" mà không giải thích. Thuật ngữ này xuất phát từ các bản nháp ban đầu của đặc tả JSP, mô tả hai mẫu sử dụng cơ bản cho các trang JSP. Trong khi các điều khoản đã biến mất khỏi tài liệu đặc tả, chúng vẫn được sử dụng phổ biến. Model 1 và Model 2 đơn giản chỉ sự vắng mặt hoặc sự hiện diện (tương ứng) của một servlet điều khiển gửi các yêu cầu từ tầng máy khách và chọn các khung nhìn.

Điều đó về cơ bản có nghĩa là có các biến thể đối với mẫu MVC để bạn luôn có thể áp dụng mẫu MVC hoặc MV tùy thuộc vào dự án của bạn. Tuy nhiên một kiến ​​trúc MVC thích hợp thực sự phải có một bộ điều khiển vì mô hình và khung nhìn không nên nói chuyện trực tiếp với nhau.