2012-01-14 32 views
6

Bất cứ ai có thể đưa ra một ví dụ về lý do tại sao nó sẽ là thuận lợi để sử dụng MVC thay vì một mô hình đơn giản và chỉ xem. Lưu ý: cho dù nó được gọi là MVC hoặc MVP (Model-View-Presenter), tôi đang nói về một nơi View nhận đầu vào, sau đó Controller sẽ trả lời sự kiện đầu vào bằng cách giải thích đầu vào thành một số hành động được thực hiện bởi Model. Khi mô hình thay đổi, Chế độ xem sẽ tự cập nhật bằng cách trả lời các sự kiện từ mô hình.Lợi thế của Model-View-Controller (MVC) so với Model-View là gì?

Điều gì là bất lợi khi đơn giản cho phép Mô hình phản hồi các sự kiện trong Chế độ xem và ngược lại?

Trong MVC, nếu tôi thay đổi mô hình theo cách ảnh hưởng đến bộ điều khiển thì tôi sẽ phải thực hiện các thay đổi trong bộ điều khiển. Trong Model-View, nếu tôi thay đổi Model, tôi sẽ phải cập nhật view.

Vì vậy, có vẻ như chúng tôi đang giới thiệu tính phức tạp bằng cách thêm phần "bộ điều khiển"?

Trả lời

4

Trong MVC, Model là mù đến môi trường xung quanh, quan điểm thể quá - đi tắt (một cách mù quáng) các sự kiện của nó đối với bộ điều khiển, nó biết nhiều hơn về khung nhìn và mô hình. Vì vậy, khi tất cả được nói và thực hiện, bộ điều khiển là phần dùng một lần 'không thể tái sử dụng' của hệ thống, vì nó là thành phần nhận biết ngữ cảnh nhất.

nếu tôi thay đổi mô hình theo một cách mà ảnh hưởng đến bộ điều khiển ...

Các mô hình nên tiếp xúc với phương pháp CRUD đơn giản theo cách như vậy mà những người sử dụng các phương pháp này không cần phải biết gì về đối tượng cập nhật được truyền, cũng không phải điều thực sự xảy ra bên trong mô hình.

Điều này có nghĩa là chế độ xem, IMO, phải thực hiện một chút công việc bằng cách tạo bản ghi đã qua, vì Bộ điều khiển được cho là không trạng thái và chế độ xem bền hơn. Bộ điều khiển được kích hoạt và 'kick-in' làm công việc của họ với một đối tượng được thông qua và không có trạng thái.

Dữ liệu được truyền được tạo bởi một số loại quy ước chung.

Hãy để tôi tiến xa hơn.Giả sử bạn có một khung nhìn, một bảng và một điều khiển có thuộc tính được bật phụ thuộc vào mục được chọn trong lưới - bạn có thể tạo một khung nhìn xử lý cả các điều khiển và logic này bên trong, và đó có thể là cách để đi trong ví dụ đơn giản như vậy.

Nhưng các chế độ xem của bạn càng có nhiều nguyên tử, chúng càng trở nên tái sử dụng nhiều hơn, vì vậy bạn tạo chế độ xem cho mọi điều khiển, có mọi điều khiển. Bây giờ bạn đang nhìn vào một tình huống mà quan điểm phải biết về nhau để đăng ký cho mình thông báo đúng ...

Đây là nơi mà bộ điều khiển bước vào, vì chúng tôi muốn gắn tất cả những phụ thuộc vào anh ta, dài hạn dùng một lần. Vì vậy, trình điều khiển quản lý loại lược đồ thông báo chế độ xem này.

Giờ đây, chế độ xem của bạn không rõ ràng vì chúng có thể độc lập, do đó có thể sử dụng lại được.

Bạn có thể mã chế độ xem mà không cần phải biết về hệ thống hoặc 'logic nghiệp vụ' như họ muốn gọi. Bạn có thể viết mã một mô hình mà không cần phải biết quá nhiều về các mục tiêu của bạn (mặc dù nó giúp chỉnh sửa mô hình để cho phép nó trả về các tập dữ liệu bạn có) .... nhưng các bộ điều khiển, chúng là cuối cùng và bạn phải có hai cái trước được làm vững chắc trước khi bạn có thể kết nối mọi thứ với nhau. Dưới đây là một điều khác cần suy nghĩ - giống như Mô hình được cho là trừu tượng và cung cấp một giao diện chung cho việc triển khai cơ bản dữ liệu mà nó đang quản lý (máy khách không biết dữ liệu đến từ một máy tính hay không.). DB, tệp, cài đặt chương trình, v.v.) - chế độ xem cũng sẽ trừu tượng ra khỏi điều khiển mà nó đang sử dụng.

Vì vậy, cuối cùng điều này có nghĩa một cái nhìn không (caveat dưới đây) nên có chức năng/tài sản mà trông như thế này:

public property BackgroundColor{get;set} 

Cũng

public function ScrollBy(x,y){} 

Nhưng thay vì:

public SetProp(string name, object val){} 

public DoCmd(string name, object val){} 

Đây là một chút contrived, và nhớ tôi đã nói cuối cùng ... và bạn hỏi tại sao đây là một ý tưởng tốt?

Với khả năng sử dụng lại, hãy xem xét rằng một ngày nào đó bạn muốn chuyển mọi thứ từ WinForms sang Flex, hoặc đơn giản muốn sử dụng thư viện điều khiển mới bị vướng víu.

Tôi nói 'port' ở đây, nhưng thực sự không phải là mục tiêu, chúng tôi không quan tâm đến việc chuyển ứng dụng cụ thể này, nhưng có các yếu tố MVC cơ bản đủ để được chuyển sang một hương vị mới - trong nội bộ, để lại một giao diện bên ngoài nhất quán và khả năng độc lập còn nguyên vẹn.

Nếu bạn không làm điều này, thì khi có thêm hương vị mới, tất cả các tham chiếu cứng của bạn để xem các thuộc tính trong bộ điều khiển (có khả năng tái sử dụng/refactorable/extendable). Điều này không có nghĩa là các trình cài đặt chung và các cmd phải là giao diện cho tất cả các khả năng xem của bạn, nhưng thay vào đó chúng phải xử lý các đặc tính 'cạnh trường hợp' cũng như các đạo cụ/cmd thông thường bạn có thể phơi bày trong truyền thống cách liên kết cứng. Hãy coi nó như một bộ xử lý 'thuộc tính mở rộng'.

Bằng cách đó, (contrived một lần nữa), giả sử bạn đang xây dựng trên một khung nơi các nút của bạn không còn có thuộc tính buttonIcon nữa. Thats mát mẻ bởi vì bạn đã có tầm nhìn xa để tạo ra một giao diện nút xem nơi buttonIcon là một thuộc tính mở rộng, và bên trong khung nhìn mã điều kiện của bạn thực hiện một no-op ngay bây giờ khi nó nhận được tập hợp/get. Tóm lại, tôi đang cố gắng nói rằng các mục tiêu mã hóa của MVC nên cung cấp cho Model và View các giao diện chung cho các thành phần cơ bản của chúng, vì vậy khi bạn mã hóa một Controller, bạn không cần phải suy nghĩ kỹ về bạn đang kiểm soát ai. Và trong khi các bộ điều khiển đang được (dường như không công bằng) được thiết lập để là con chiên hy sinh trong thời gian dài của khả năng sử dụng lại - điều này không có nghĩa là tất cả các bộ điều khiển của bạn được mệnh cho cái chết. Họ hy vọng là nhỏ, vì rất nhiều "suy nghĩ" của họ đã bị đẩy vào các mô hình và khung nhìn bán thông minh và các bộ điều khiển khác (ví dụ: Bộ điều khiển để sắp xếp một Lưới hoặc Thao tác một TreeView) - vì vậy chúng nhỏ có thể dễ dàng xem xét và đủ điều kiện để tái sử dụng trong dự án tiếp theo của bạn - hoặc nhân bản và tinh chỉnh để trở thành phù hợp.

+0

Tôi sẽ đưa ra một ví dụ đơn giản về lý do tại sao tôi không thấy lợi thế. Giả sử chúng ta đang nói về một chiếc xe hơi. Nút tăng tốc của Chế độ xem ô tô được nhấp, Bộ điều khiển phản hồi bằng cách gọi Model.Accelerate(), sau đó tốc độ của Model được thay đổi và View phản hồi sự kiện Model và cập nhật tốc độ đọc trên màn hình. Bây giờ, trong Model-View (MV) Khi nhấn nút, Xem các cuộc gọi Model.Accelerate() và cùng xảy ra mà không có bộ điều khiển tham gia. Trong MVC nếu tôi thay đổi Accelerate() thành Tăng tốc độ(), tôi sẽ phải cập nhật bộ điều khiển để gọi phương pháp này. Trong trường hợp của MV, tôi sẽ thực hiện cập nhật tương tự nhưng với View. –

+0

Tiếp tục bình luận trước: Vì vậy, những lợi thế chỉ áp dụng trong các trường hợp sau: 1. Quan điểm của bạn không cụ thể đối với dự án hiện tại của bạn (điều này hiếm khi xảy ra). 2. Tôi không thể nghĩ ra được !!! (có thể thiếu kinh nghiệm). –

+0

Bạn có một ví dụ 1-to ở đó. Quan điểm phải biết tất cả về mô hình trong MỌI CÁCH nó ảnh hưởng đến mô hình. Đó là một nhóm phụ thuộc tất cả ở một nơi. Trong khi với bộ điều khiển, cụm đó được tách ra - một bộ điều khiển riêng biệt cho mỗi sự kiện - và nếu một cái gì đó fancier phải xảy ra với mô hình trên sự kiện, sự thay đổi xảy ra trong bộ điều khiển (tức là, khả năng điều khiển tái sử dụng tăng lên chỉ áp dụng cho một sự kiện). Với cách của bạn, mọi cải tiến/bổ sung sẽ giảm khả năng sử dụng lại lượt xem. –

1

Nó thực sự làm giảm độ phức tạp bằng cách tách logic luồng công việc khỏi logic miền. Nó cũng làm cho nó dễ dàng hơn để viết các bài kiểm tra đơn vị và làm cho ứng dụng của bạn dễ dàng hơn để duy trì và mở rộng.

Hãy tưởng tượng nếu bạn muốn thêm loại dữ liệu mới. Với cách tiếp cận ở trên, bạn có thể sẽ sao chép rất nhiều luồng công việc trong lớp mới vì nó có khả năng sẽ được kết hợp chặt chẽ với logic miền.

Kỷ luật liên quan đến việc tách logic luồng công việc thành bộ điều khiển giúp bạn có ít khả năng phụ thuộc hơn giữa luồng công việc và logic miền. Việc thêm kiểu dữ liệu mới sau đó sẽ đơn giản hơn, bạn tạo đối tượng miền mới và xem bạn có thể sử dụng lại bao nhiêu bộ điều khiển, ví dụ: bằng cách thừa kế từ một lớp siêu điều khiển.

Nó cũng sẽ làm cho việc thay đổi khung công tác trở nên dễ dàng hơn trong tương lai - mô hình có thể sẽ không thay đổi quá nhiều và do đó sẽ dễ di chuyển hơn.

Có nói rằng, bạn có thể muốn xem xét MVVM tùy thuộc vào những gì bạn đang sử dụng như lớp trình bày của bạn: Benefits of MVVM over MVC

1

Ưu điểm của MVC/P (Tôi đang nói về Giám sát điều khiển ở đây) trong MV bao gồm:

  • Bạn có thể xử lý dữ liệu phức tạp ràng buộc mã trong bộ điều khiển, nếu có yêu cầu.

  • Bạn có thể kiểm tra logic trình bày phức tạp đó mà không cần khung kiểm tra giao diện người dùng.

  • Bạn cũng có thể có một nhà thiết kế đồ họa làm cho chế độ xem của bạn và không nhìn thấy mã của bạn và không làm hỏng mã của bạn khi họ sửa các chế độ xem của bạn.

Các vấn đề liên quan