MVC: bộ điều khiển của tôi dường như vô dụng một nửa thời gian. Đây co phải vân đê?


9

Thông thường khi tôi thiết kế một chương trình với MVC, bộ điều khiển là vô dụng một nửa thời gian.

Ý tôi là thế này: một cái gì đó xảy ra trên khung nhìn (ví dụ như một nút bấm). Chế độ xem sau đó thông báo cho bộ điều khiển. Bộ điều khiển sau đó trực tiếp ủy quyền cho mô hình và không làm gì khác vì nó không có gì để làm.

Ví dụ:

Người dùng nhấn nút 'Color Blue'> view báo cho bộ điều khiển controller.colorBlue()> bộ điều khiển cho model model.colorBlue()> màu mô hình có màu xanh lam.

Trong ví dụ này, bộ điều khiển dường như vô dụng. Nó không thêm gì. Quan điểm cũng có thể đã nói thẳng với mô hình.

Tuy nhiên, nửa còn lại, bộ điều khiển thực hiện một số loại trung gian giữa chế độ xem và mô hình.

Câu hỏi của tôi là: làm thế nào phổ biến trong cấu trúc MVC? Có hợp lý không khi một nửa thời gian bộ điều khiển của tôi có vẻ không cần thiết? Hay đây là một vấn đề? Đây có phải là phổ biến? Làm thế nào tôi nên tiếp cận điều này?

Nếu câu hỏi của tôi không đủ rõ ràng, xin vui lòng nói như vậy.


1
như được gợi ý bởi RobertHarvey, đối với ví dụ cụ thể này, có thể tốt hơn nếu controller.colorBlue()thực sự sau đó gọi model.setColor(0, 0, 255);. Một lý do để phân tách giữa Model và View là thường xảy ra trường hợp bạn có nhiều thành phần UI để thể hiện một trạng thái duy nhất trong mô hình (ví dụ: một mục được kiểm tra trong menu, thanh công cụ bị chán nản và con trỏ thay đổi thành màu biểu tượng tất cả tương ứng với trường công cụ hiện được chọn trong mô hình), với phân tách MVC, mô hình sẽ không phải lo lắng về việc đồng bộ hóa các thành phần UI khác nhau.
Lie Ryan

Câu trả lời:


12

Bạn đang đánh giá thấp tầm quan trọng của việc có một lớp trừu tượng giữa Giao diện người dùng và Mô hình của bạn. Bộ điều khiển hoàn thành chức năng này 100% thời gian.

Ví dụ của bạn model.colorBlue()là một chút đặc biệt. Trong một mô hình thực tế, đây có lẽ sẽ là một phương pháp CRUD. Vì vậy, nút của bạn có thể là nút Tạo khách hàng, phương thức điều khiển của bạn sẽ là CreateCustomer()và Mô hình của bạn sẽ là CreateCustomer(). Chắc chắn, bạn chỉ cần thực hiện cuộc gọi.

Nhưng nếu bạn cần thay đổi cách thức hoạt động của mô hình thì sao? Nếu Chế độ xem của bạn đang gọi trực tiếp cho mô hình của bạn, ứng dụng của bạn sẽ bị hỏng nếu bạn thay đổi Mô hình. Các phương thức điều khiển cung cấp "điểm truy cập" cho Chế độ xem của bạn; bạn có thể thực hiện một sửa đổi đơn giản cho phương thức điều khiển, có thể bằng cách thay đổi lệnh gọi Model CreateCustomerWithVerification()và mọi thứ vẫn hoạt động.

Lý do tương tự áp dụng cho việc có Lớp dịch vụ. Thay vì chỉ đơn giản là có các phương thức CRUD trong mô hình của bạn, bạn nên có các hành động kinh doanh. Bằng cách đó, bạn giữ logic nghiệp vụ ra khỏi bộ điều khiển của mình và cho phép sử dụng Mô hình ở một nơi khác, có thể trong ứng dụng WPF.

Hãy nghĩ về Bộ điều khiển như một "Xưởng đóng tàu." Nó phải là một trung gian, yêu cầu trung gian giữa UI và Model của bạn, nhưng các phương thức điều khiển nên có càng ít logic trong chúng càng tốt.


Hãy để tôi xem nếu tôi hiểu những gì bạn đang nói. Bạn đang nói rằng ngay cả khi bộ điều khiển chỉ đơn giản ủy quyền trực tiếp cho mô hình, vẫn rất tốt để có một giữa chế độ xem và mô hình vì điều này: nếu mô hình thay đổi, tất cả các đối tượng gọi phương thức của nó có thể phải thay đổi. Nếu khung nhìn là khung nhìn gọi các phương thức trên mô hình, thì nó sẽ phải thay đổi. Nếu bộ điều khiển gọi các phương thức, nó cũng sẽ phải thay đổi. Nhưng sự khác biệt là chế độ xem có trách nhiệm hiển thị UI - một phần quan trọng của ứng dụng. Tuy nhiên, trách nhiệm duy nhất của người kiểm soát là chính xác - giao tiếp [..]
Aviv Cohn

với người mẫu. Và vì điều này, tốt hơn là thay đổi bộ điều khiển khi mô hình thay đổi (và giữ nguyên chế độ xem), sau đó thay đổi chế độ xem.
Manila Cohn

3
Vâng, điều đó hoàn toàn chính xác. Sự phân tách được cung cấp bởi lớp Trình điều khiển cho phép thay đổi trong Mô hình mà không phá vỡ giao diện người dùng hoặc định tuyến.
Robert Harvey

Tôi hiểu rồi. Và chỉ cần chắc chắn: tốt hơn là thay đổi bộ điều khiển so với chế độ xem khi mô hình thay đổi, vì chế độ xem chịu trách nhiệm cho logic quan trọng - hiển thị UI. Thay đổi về mặt lý thuyết sẽ khiến tất cả các mã khác gặp rủi ro. Tuy nhiên, mục đích duy nhất của bộ điều khiển là chính xác, giao tiếp các công cụ với mô hình và do đó phụ thuộc vào mô hình - vì vậy chế độ xem không phải. Và bởi vì bộ điều khiển không bao gồm bất kỳ logic quan trọng nào khác, tốt hơn là bộ điều khiển thay đổi khi mô hình thực hiện, thay vì chế độ xem phải thay đổi. Nó thật sự đúng?
Manila Cohn

Vâng, về cơ bản. Bằng cách cách ly các thay đổi như vậy đối với bề mặt API của Mô hình và các phương thức của bộ điều khiển, bạn cung cấp khả năng tách rời tốt hơn khỏi UI. Chế độ xem không bao giờ phải thay đổi do kết quả của thay đổi xảy ra đối với logic nghiệp vụ, trừ khi Chế độ xem cũng cần phản ánh các thay đổi trong cách thức hoạt động của doanh nghiệp. Nói cách khác, Chế độ xem cần có càng ít kiến ​​thức về các đối tượng Mô hình càng tốt; đây là lý do tại sao chúng ta có những thứ như ViewModels (cung cấp sự tách rời bổ sung từ Mô hình).
Robert Harvey

-1

Trong khi mã hóa, bạn có thể nghĩ theo cách này:

  • Tôi có thể thay đổi chế độ xem sang một thứ khác (bảng điều khiển, dịch vụ) hoặc cùng một bộ điều khiển cho chế độ xem khác không?
  • Tôi có thể thay đổi mô hình để xử lý cơ sở dữ liệu khác nhau hoặc ghi vào một số dịch vụ bên ngoài không?

Trong trường hợp của bạn, có vẻ như bạn đang đưa logic miền vào mô hình và điều đó sẽ gây ra sự cố cho bạn nếu bạn muốn thay đổi nó: bạn sẽ phải sao chép các phương thức như "model.colorBlue" sang mô hình mới.

Và điều gì sẽ xảy ra nếu định nghĩa về "màu xanh" thay đổi? Bạn sẽ phải thay đổi nó 2 mô hình. Ngoài ra trong bộ điều khiển, bạn không nên ghi trực tiếp vào cơ sở dữ liệu của mình, nhưng như Lie Ryan đã chỉ bạn nên sử dụng model.setColor.

Tương tự với quan điểm. Nếu bạn bắt đầu đưa logic hoặc xác thực vào chế độ xem thì nếu bạn muốn thay đổi chế độ xem, bạn sẽ phải sao chép tất cả chức năng đó.

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.