Câu hỏi MVP và MVC là gì và sự khác biệt là gì?


Khi nhìn xa hơn RAD (kéo-thả và cấu hình) cách xây dựng giao diện người dùng mà nhiều công cụ khuyến khích bạn có khả năng đi qua ba mẫu thiết kế được gọi là Bộ điều khiển xem mô hình, Model-View-Presenter và Model-View-ViewModel. Câu hỏi của tôi có ba phần:

  1. Những vấn đề gì làm các mẫu này giải quyết?
  2. Chúng giống nhau như thế nào?
  3. Họ khác nhau như thế nào?

1839
2017-08-05 10:06


gốc


mvc.givan.se/#mvp - givanse
IDK, nhưng được cho là MVC gốc, nó có nghĩa là được sử dụng trong nhỏ. Mỗi nút, nhãn, vv, có đối tượng điều khiển và khung nhìn riêng của nó, hoặc ít nhất đó là những gì Bác Bob tuyên bố. Tôi nghĩ anh ấy đang nói về Smalltalk. Tra cứu các cuộc nói chuyện của anh ấy trên YouTube, chúng thật hấp dẫn. - still_dreaming_1
MVP thêm một lớp bổ sung của indirection bằng cách chia View-Controller thành View và Presenter ... - the_prole
Sự khác biệt chính là trong MVC Controller không truyền bất kỳ dữ liệu nào từ Model đến View. Nó chỉ thông báo cho View để lấy dữ liệu từ chính Model đó. Tuy nhiên, trong MVP, không có kết nối giữa View và Model. Bản thân người trình bày nhận bất kỳ dữ liệu nào cần thiết từ Mô hình và chuyển nó đến Chế độ xem để hiển thị. Thêm vào điều này cùng với một mẫu Android trong tất cả các mẫu kiến ​​trúc là ở đây: digigene.com/category/android/android-architecture - Ali Nem


Các câu trả lời:


Model-View-Presenter

Trong MVP, Người trình bày chứa logic nghiệp vụ giao diện người dùng cho Chế độ xem. Tất cả các cuộc gọi từ đại biểu Xem trực tiếp đến Người trình bày. Presenter cũng được tách riêng trực tiếp từ View và nói chuyện với nó thông qua một giao diện. Điều này là để cho phép chế nhạo Chế độ xem trong một bài kiểm tra đơn vị. Một thuộc tính chung của MVP là phải có rất nhiều cách điều phối hai chiều. Ví dụ, khi ai đó nhấp vào nút "Lưu", trình xử lý sự kiện sẽ đại diện cho phương thức "OnSave" của Người trình bày. Khi lưu xong, Presenter sẽ gọi lại View thông qua giao diện của nó để View có thể hiển thị lưu đã hoàn thành.

MVP có xu hướng là một mô hình rất tự nhiên để đạt được bản trình bày tách biệt trong các biểu mẫu web. Lý do là View luôn luôn được tạo đầu tiên bởi ASP.NET runtime. Bạn có thể tìm hiểu thêm về cả hai biến thể.

Hai biến thể chính

Chế độ xem thụ động: Chế độ xem càng câm càng tốt và chứa logic gần như bằng không. Presenter là một người đàn ông trung gian nói chuyện với View và Model. View và Model được che chắn hoàn toàn với nhau. Mô hình có thể tăng sự kiện, nhưng Người trình bày đăng ký với họ để cập nhật Chế độ xem. Trong chế độ xem thụ động, không có ràng buộc dữ liệu trực tiếp, thay vào đó chế độ xem hiển thị các thuộc tính setter mà Trình dẫn sử dụng để đặt dữ liệu. Tất cả các trạng thái được quản lý trong Presenter chứ không phải là View.

  • Pro: bề mặt thử nghiệm tối đa; tách biệt rõ ràng Chế độ xem và Mô hình
  • Con: công việc nhiều hơn (ví dụ tất cả các thuộc tính setter) như bạn đang làm tất cả các dữ liệu ràng buộc chính mình.

Kiểm soát giám sát: Người thuyết trình xử lý cử chỉ của người dùng. Chế độ xem liên kết với Mô hình trực tiếp thông qua ràng buộc dữ liệu. Trong trường hợp này, đó là công việc của người trình bày để truyền mô hình cho khung nhìn để nó có thể liên kết với nó. Người trình bày cũng sẽ chứa logic cho các cử chỉ như nhấn nút, điều hướng, v.v.

  • Pro: bằng cách tận dụng databinding số lượng mã được giảm.
  • Con: có ít bề mặt có thể kiểm tra (vì ràng buộc dữ liệu) và có ít đóng gói hơn trong Chế độ xem vì nó nói trực tiếp với Mô hình.

Bộ điều khiển xem mô hình

bên trong MVC, Bộ điều khiển chịu trách nhiệm xác định Chế độ xem nào sẽ hiển thị để phản hồi bất kỳ hành động nào kể cả khi ứng dụng tải. Điều này khác với MVP nơi các hành động định tuyến thông qua Xem tới Người trình bày. Trong MVC, mọi hành động trong Chế độ xem tương quan với cuộc gọi đến Bộ điều khiển cùng với một hành động. Trong web, mỗi hành động liên quan đến một cuộc gọi đến một URL ở phía bên kia trong đó có một Controller phản hồi. Khi Bộ điều khiển đã hoàn thành quá trình xử lý, Bộ điều khiển sẽ trả về Chế độ xem chính xác. Trình tự tiếp tục theo cách đó trong suốt vòng đời của ứng dụng:

Hành động trong chế độ xem
        -> Gọi để điều khiển
        -> Logic điều khiển
        -> Controller trả về View.

Một khác biệt lớn khác về MVC là View không liên kết trực tiếp với Model. Chế độ xem chỉ đơn giản là hiển thị và hoàn toàn không trạng thái. Trong việc triển khai MVC, View thường sẽ không có bất kỳ logic nào trong đoạn mã phía sau. Điều này trái với MVP, nơi nó là hoàn toàn cần thiết bởi vì, nếu View không ủy thác cho Presenter, nó sẽ không bao giờ được gọi.

Mô hình trình bày

Một mô hình khác để xem xét là Mô hình trình bày mẫu. Trong mô hình này không có Presenter. Thay vào đó, Chế độ xem liên kết trực tiếp với Mô hình trình bày. Mô hình trình bày là một Mô hình được tạo riêng cho Chế độ xem. Điều này có nghĩa là Mô hình này có thể phơi bày các thuộc tính mà một người sẽ không bao giờ đưa vào một mô hình miền vì nó sẽ là một sự vi phạm các mối quan tâm tách biệt. Trong trường hợp này, Mô hình trình bày liên kết với mô hình miền và có thể đăng ký các sự kiện đến từ Mô hình đó. Chế độ xem sau đó đăng ký các sự kiện đến từ Mô hình trình bày và tự cập nhật cho phù hợp. Mô hình trình bày có thể hiển thị các lệnh mà khung nhìn sử dụng để gọi các hành động. Ưu điểm của phương pháp này là bạn về cơ bản có thể loại bỏ hoàn toàn mã sau khi PM hoàn toàn đóng gói tất cả các hành vi cho khung nhìn. Mẫu này là một ứng cử viên rất mạnh để sử dụng trong các ứng dụng WPF và cũng được gọi là Model-View-ViewModel.

Đây là một Bài viết MSDN về Mô hình trình bày và một phần trong Hướng dẫn ứng dụng tổng hợp cho WPF (cựu Prism) về Mẫu trình bày riêng biệt


1803
2017-08-05 10:21



Bạn có thể làm rõ cụm từ này không? Điều này khác với MVP nơi các hành động định tuyến thông qua Xem tới Người trình bày. Trong MVC, mọi hành động trong Chế độ xem tương quan với cuộc gọi đến Bộ điều khiển cùng với một hành động. Đối với tôi, nó có vẻ giống như vậy, nhưng tôi chắc chắn rằng bạn đang mô tả một cái gì đó khác nhau. - Panzercrisis
@Panzercrisis Tôi không chắc đây có phải là ý của tác giả hay không, nhưng đây là điều tôi nghĩ họ đang cố nói. Giống như câu trả lời này - stackoverflow.com/a/2068/74556 đề cập, trong MVC, phương pháp điều khiển dựa trên hành vi - nói cách khác, bạn có thể ánh xạ nhiều chế độ xem (nhưng cùng một hành vi) cho một bộ điều khiển duy nhất. Trong MVP, người trình bày được ghép gần hơn với chế độ xem và thường dẫn đến ánh xạ gần với từng người một hơn, tức là hành động xem bản đồ theo phương thức của người trình bày tương ứng. Bạn thường sẽ không ánh xạ các hành động của chế độ xem khác cho phương thức của người trình bày khác (từ chế độ xem khác). - Dustin Kendall


Tôi viết blog về điều này trong khi trở lại, trích dẫn Bài viết tuyệt vời của Todd Snyder về sự khác biệt giữa hai:

Dưới đây là những khác biệt chính giữa   các mẫu:

Mẫu MVP

  • Chế độ xem được kết hợp lỏng lẻo với mô hình. Người trình bày là   chịu trách nhiệm ràng buộc mô hình   chế độ xem.
  • Kiểm tra đơn vị dễ dàng hơn vì tương tác với chế độ xem là thông qua   một giao diện
  • Thường xem để trình bày bản đồ từ một đến một. Chế độ xem phức tạp có thể có   nhiều diễn giả.

Mẫu MVC

  • Bộ điều khiển dựa trên hành vi và có thể được chia sẻ trên   lượt xem
  • Có thể chịu trách nhiệm xác định chế độ xem nào sẽ hiển thị

Đó là giải thích tốt nhất trên trang web mà tôi có thể tìm thấy.


385
2017-07-06 22:18



Tôi không hiểu làm thế nào trong quan điểm có thể được kết hợp nhiều hơn hoặc ít hơn chặt chẽ với mô hình khi trong cả hai trường hợp toàn bộ điểm là để hoàn toàn decouple chúng. Tôi không ngụ ý bạn nói điều gì đó sai trái - chỉ nhầm lẫn với ý của bạn. - Bill K
@pst: với MVP nó thực sự là 1 View = 1 Presenter. Với MVC, Bộ điều khiển có thể điều chỉnh nhiều chế độ xem. Đó là nó, thực sự. Với mô hình "tab", hãy tưởng tượng mỗi tab có Trình bày riêng của nó thay vì có một Bộ điều khiển cho tất cả các tab. - Jon Limjap
Ban đầu có hai loại bộ điều khiển: một loại mà bạn cho là được chia sẻ trên nhiều chế độ xem và những người là chế độ xem cụ thể, chủ yếu được nhắm đến để thích ứng với giao diện của bộ điều khiển được chia sẻ. - Acsor
@JonLimjap Có nghĩa là gì theo một lượt xem? Trong bối cảnh lập trình iOS, nó có một màn hình không? Điều này làm cho bộ điều khiển của iOS giống MVP hơn MVC? (Mặt khác, bạn cũng có thể có nhiều bộ điều khiển iOS trên mỗi màn hình) - huggie
Minh họa sơ đồ của Well về MVC hoàn toàn mâu thuẫn với ý tưởng tách View và Model. Nếu bạn nhìn vào biểu đồ, nó nói Model updates View (mũi tên từ Model to View). Trong đó vũ trụ là một hệ thống, nơi mà Mô hình trực tiếp tương tác với View, một cái tách rời? - Ash


Đây là một sự đơn giản hóa của nhiều biến thể của các mẫu thiết kế này, nhưng đây là cách tôi muốn suy nghĩ về sự khác biệt giữa hai loại.

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



Đây là một mô tả tuyệt vời của sơ đồ, cho thấy sự cô lập trừu tượng và hoàn toàn của bất kỳ GUI nào có liên quan (công cụ xem) từ API của người trình bày. Một điểm nhỏ: Một người trình bày chính có thể được sử dụng khi chỉ có một người trình bày, thay vì một người trình bày, nhưng sơ đồ của bạn là sơ đồ sạch nhất. IMO, sự khác biệt lớn nhất giữa MVC / MVP là MVP cố gắng giữ cho khung nhìn hoàn toàn không có gì khác ngoài hiển thị của trạng thái xem hiện tại (xem dữ liệu), đồng thời cũng không cho phép xem bất kỳ kiến ​​thức nào về các đối tượng Model. Vì vậy, các giao diện, cần phải có, để tiêm trạng thái đó.
Bức tranh đẹp. Tôi sử dụng MVP khá nhiều, vì vậy tôi muốn làm một điểm. Theo kinh nghiệm của tôi, các thuyết trình viên cần nói chuyện với nhau khá thường xuyên. Điều tương tự cũng đúng đối với Mô hình (hoặc đối tượng Kinh doanh). Bởi vì những "đường màu xanh" bổ sung này của truyền thông sẽ nằm trong pic MVP của bạn, các mối quan hệ Người mẫu-Người mẫu có thể trở nên khá vướng víu. Do đó, tôi có xu hướng giữ mối quan hệ một người-một-một-một so với một-nhiều. Có, nó đòi hỏi một số phương thức ủy nhiệm bổ sung trên Model, nhưng nó làm giảm nhiều nhức đầu nếu API của Model thay đổi hoặc cần tái cấu trúc. - splungebob
Ví dụ MVC là sai; có mối quan hệ chặt chẽ 1: 1 giữa lượt xem và bộ điều khiển. Theo định nghĩa, một bộ điều khiển diễn giải đầu vào cử chỉ của con người để tạo ra các sự kiện cho mô hình và xem giống nhau cho một điều khiển đơn. Đơn giản hơn, MVC được thiết kế chỉ để sử dụng với các widget riêng lẻ. Một tiện ích, một chế độ xem, một điều khiển. - Samuel A. Falvo II
@ SamuelA.FalvoII không phải luôn luôn, có một 1: Nhiều giữa các bộ điều khiển và khung nhìn trong ASP.NET MVC: stackoverflow.com/questions/1673301/… - StuperUser
@StuperUser - Không chắc tôi đang nghĩ gì khi tôi viết điều đó. Bạn nói đúng, tất nhiên, và nhìn lại những gì tôi đã viết, tôi phải tự hỏi liệu tôi có một số bối cảnh khác trong tâm trí mà tôi không nói rõ. Cảm ơn vì sự đúng đắn của bạn. - Samuel A. Falvo II


Dưới đây là các minh họa thể hiện luồng truyền thông

enter image description here 

enter image description here


210
2017-08-25 21:22



Tôi có một câu hỏi liên quan đến sơ đồ MVC. Tôi không nhận được phần mà xem ra đi để lấy dữ liệu. Tôi sẽ nghĩ rằng bộ điều khiển sẽ chuyển tiếp đến xem với các dữ liệu cần thiết. - Brian Rizo
Nếu người dùng nhấp vào một nút, cách đó không tương tác với chế độ xem? Tôi cảm thấy như trong MVC, người dùng tương tác với chế độ xem nhiều hơn bộ điều khiển - Jonathan
Tôi biết đây là một câu trả lời cũ - nhưng bất cứ ai có thể trả lời trên @JonathanLeaders điểm? Tôi đến từ một nền winforms trừ khi bạn đã làm một số mã hóa rất độc đáo, khi bạn nhấp vào giao diện người dùng / xem được kiến ​​thức về nhấp chuột đó trước khi bất cứ điều gì khác. Ít nhất, theo như tôi biết? - Rob P.
@RobP. Tôi nghĩ rằng các loại biểu đồ này luôn có xu hướng quá phức tạp hoặc quá đơn giản. Imo dòng chảy của biểu đồ MVP cũng đúng cho một ứng dụng MVC. Có thể có các biến thể, tùy thuộc vào các tính năng ngôn ngữ (dữ liệu ràng buộc / người quan sát), nhưng cuối cùng, ý tưởng là tách rời chế độ xem khỏi dữ liệu / logic của ứng dụng. - Luca Fülbier
@JonathanLeaders Mọi người có có thật không những điều khác nhau trong tâm trí khi họ nói "MVC". Người tạo ra biểu đồ này có lẽ là Web MVC cổ điển trong tâm trí, nơi "đầu vào người dùng" là các yêu cầu HTTP và "chế độ xem được trả lại cho người dùng" là một trang HTML được hiển thị. Vì vậy, bất kỳ tương tác nào giữa người dùng và chế độ xem đều "không tồn tại" từ góc nhìn của tác giả của ứng dụng Web MVC cổ điển. - cubuspl42


MVP là không phải nhất thiết phải là một kịch bản mà View là phụ trách (xem MVP của Taligent chẳng hạn).
Tôi thấy thật không may là mọi người vẫn đang rao giảng điều này như một khuôn mẫu (Xem phụ trách) như trái ngược với một khuôn mẫu chống đối vì nó mâu thuẫn "Nó chỉ là một cái nhìn" (Pragmatic Programmer). "Đó chỉ là một chế độ xem" cho biết rằng lượt xem cuối cùng được hiển thị cho người dùng là mối quan tâm thứ cấp của ứng dụng. Mô hình MVP của Microsoft làm cho việc sử dụng lại Chế độ xem trở nên khó khăn hơn nhiều và thuận tiện bào chữa cho nhà thiết kế của Microsoft không khuyến khích thực hành xấu.

Để hoàn toàn thẳng thắn, tôi nghĩ rằng các mối quan tâm cơ bản của MVC giữ đúng cho bất kỳ thực hiện MVP và sự khác biệt là gần như hoàn toàn ngữ nghĩa. Miễn là bạn đang tách biệt các mối quan tâm giữa chế độ xem (hiển thị dữ liệu), bộ điều khiển (khởi tạo và điều khiển tương tác người dùng) và mô hình (dữ liệu và / hoặc dịch vụ cơ bản) thì bạn sẽ đạt được lợi ích của MVC . Nếu bạn đang đạt được những lợi ích thì ai thực sự quan tâm cho dù mô hình của bạn là MVC, MVP hoặc giám sát điều khiển? Duy nhất thực mô hình vẫn là MVC, phần còn lại chỉ là những hương vị khác nhau của nó.

Xem xét điều này bài viết rất thú vị mà toàn diện liệt kê một số các triển khai khác nhau này. Bạn có thể lưu ý rằng tất cả chúng đều cơ bản làm điều tương tự nhưng hơi khác một chút.

Cá nhân tôi nghĩ MVP chỉ mới được giới thiệu gần đây như một thuật ngữ hấp dẫn để giảm bớt các tranh luận giữa các bigots ngữ nghĩa, người tranh luận liệu một cái gì đó thực sự là MVC hay không hoặc để biện minh cho các công cụ phát triển ứng dụng nhanh của Microsofts. Không một trong những lý do này trong sách của tôi biện minh cho sự tồn tại của nó như là một mẫu thiết kế riêng biệt.


149
2017-08-06 22:51



Tôi đã đọc một số câu trả lời và blog về sự khác biệt giữa MVC / MVP / MVVM / etc '. Trong thực tế, khi bạn đang xuống để kinh doanh, đó là tất cả như nhau. Nó không thực sự quan trọng cho dù bạn có một giao diện hay không, và cho dù bạn đang sử dụng một setter (hoặc bất kỳ tính năng ngôn ngữ khác). Có vẻ như sự khác biệt giữa các mẫu này được sinh ra từ sự khác biệt của các triển khai khung khác nhau, chứ không phải là vấn đề khái niệm. - Michael
Tôi sẽ không gọi MVP chống mẫu, như sau trong bài ".. phần còn lại [bao gồm MVP] chỉ là những hương vị khác nhau của [MVC] ..", có nghĩa là nếu MVP là một mẫu chống, thì MVC ... nó chỉ là một hương vị cho một cách tiếp cận của khung công tác khác. (Bây giờ, một số riêng Việc triển khai MVP có thể nhiều hơn hoặc ít hơn mong muốn riêng Triển khai MVC cho các tác vụ khác nhau ...)
@Quibblsome: "Cá nhân tôi nghĩ MVP mới được giới thiệu gần đây như là một thuật ngữ hấp dẫn để giảm bớt tranh luận giữa các bigots ngữ nghĩa, cho rằng điều gì đó thực sự là MVC hay không [...] Không có lý do nào trong sách của tôi. mẫu thiết kế riêng biệt. ”. Nó khác đủ để làm cho nó khác biệt. Trong MVP, xem có thể là bất cứ điều gì hoàn thành một giao diện được xác định trước (xem trong MVP là một thành phần độc lập). Trong MVC, Controller được thực hiện cho một khung nhìn cụ thể (nếu các quan hệ của các quan hệ có thể khiến ai đó cảm thấy có giá trị một thuật ngữ khác). - Hibou57
@ Hibou57, không có gì để ngăn chặn MVC tham chiếu chế độ xem dưới dạng giao diện hoặc tạo bộ điều khiển chung cho một số chế độ xem khác nhau. - Quibblesome
@quibblesome thực sự, có. Bộ điều khiển, theo định nghĩa, ràng buộc chặt chẽ với quan điểm tương ứng của họ, cho công việc của họ là để giải thích cử chỉ của con người (bấm phím, cập nhật chuột, vv) vào các sự kiện cho điều khiển riêng lẻ trên cửa sổ. Đây là lý do tại sao bạn có một bộ điều khiển nghiêm ngặt, một mối quan hệ xem. Bộ điều khiển là không bao giờ dành cho việc sử dụng toàn bộ biểu mẫu. Đối với việc sử dụng toàn bộ biểu mẫu, Mô hình ứng dụng (còn gọi là Mô hình trình bày) đã tồn tại, phù hợp hơn với mục đích đó. Vì GUI không phải Smalltalk không dựa vào MVC để thực hiện điều khiển, MVC có ý nghĩa tương đối ít trong thực tế. - Samuel A. Falvo II


MVP: lượt xem phụ trách.

Quan điểm, trong hầu hết các trường hợp, tạo ra người trình bày của nó. Người trình bày sẽ tương tác với mô hình và điều khiển khung nhìn thông qua một giao diện. Chế độ xem đôi khi sẽ tương tác với người trình bày, thường thông qua một số giao diện. Điều này đi xuống để thực hiện; Bạn có muốn chế độ xem gọi các phương thức trên trình dẫn hoặc bạn có muốn chế độ xem có các sự kiện mà người trình bày lắng nghe không? Nó tóm lại điều này: Khung nhìn biết về người trình bày. Chế độ xem đại biểu cho người trình bày.

MVC: bộ điều khiển phụ trách.

Bộ điều khiển được tạo hoặc truy cập dựa trên một số sự kiện / yêu cầu. Bộ điều khiển sau đó tạo chế độ xem thích hợp và tương tác với mô hình để định cấu hình thêm chế độ xem. Nó tóm tắt: bộ điều khiển tạo và quản lý khung nhìn; xem là nô lệ cho bộ điều khiển. Khung nhìn không biết về bộ điều khiển.


90
2017-12-20 02:10



"Chế độ xem không biết về Bộ điều khiển". Tôi nghĩ rằng bạn có nghĩa là xem không có liên hệ trực tiếp với mô hình? - Lotus Notes
xem nên không bao giờ biết về mô hình trong eiether một. - Brian Leahy
@Brian: "The View, trong hầu hết các trường hợp, tạo ra nó là Presenter." Tôi hầu như thấy điều ngược lại, với Presenter khởi chạy cả Model và View. Vâng, View cũng có thể khởi chạy Presenter, nhưng điểm đó không thực sự là đặc biệt nhất. Điều quan trọng nhất xảy ra sau này trong suốt cuộc đời. - Hibou57
Bạn có thể muốn chỉnh sửa câu trả lời để giải thích thêm: Vì Chế độ xem không biết về Bộ điều khiển, hành động của người dùng được thực hiện như thế nào trên các phần tử 'trực quan' mà người dùng nhìn thấy trên màn hình (tức là Chế độ xem), được truyền tới Bộ điều khiển ... - Ash


enter image description here

-Bộ điều khiển xem mô hình

Đầu vào được hướng vào Bộ điều khiển trước, không phải là chế độ xem. Đầu vào đó có thể đến từ một người dùng tương tác với một trang, nhưng nó cũng có thể chỉ đơn giản là nhập một URL cụ thể vào một trình duyệt. Trong cả hai trường hợp, một Controller của nó được giao tiếp với nhau để khởi động một số chức năng. Có một mối quan hệ nhiều-một giữa Controller và View. Đó là bởi vì một bộ điều khiển duy nhất có thể chọn các chế độ xem khác nhau được hiển thị dựa trên hoạt động đang được thực thi. Lưu ý mũi tên một chiều từ Bộ điều khiển đến Chế độ xem. Điều này là do Chế độ xem không có bất kỳ kiến ​​thức hoặc tham chiếu nào đến bộ điều khiển. Bộ điều khiển không truyền lại Mô hình, do đó, có kiến ​​thức giữa Chế độ xem và Mô hình dự kiến ​​sẽ được truyền vào trong đó, nhưng không phải là Bộ điều khiển phân phối nó.

MVP (Trình xem mô hình)

Đầu vào bắt đầu bằng Chế độ xem, không phải là Trình bày. Có một ánh xạ một-một giữa Chế độ xem và Người trình bày được liên kết. Chế độ xem giữ tham chiếu đến Người trình bày. Người trình bày cũng phản ứng với các sự kiện được kích hoạt từ Chế độ xem, do đó, nó nhận thức được Chế độ xem được liên kết với Chế độ xem. Người trình bày cập nhật Chế độ xem dựa trên các hành động được yêu cầu mà nó thực hiện trên Mô hình, nhưng Chế độ xem không phải là Nhận thức về mô hình.

Để biết thêm Tài liệu tham khảo


62
2017-08-05 10:22



Nhưng trong MVP mẫu, khi ứng dụng tải lần đầu tiên, không phải người trình bày có chịu trách nhiệm tải chế độ xem đầu tiên không? Ví dụ như khi chúng tôi tải ứng dụng facebook, không phải là người trình bày chịu trách nhiệm tải trang đăng nhập? - viper
Một liên kết từ Model to View trong MVC? Bạn có thể muốn chỉnh sửa câu trả lời của bạn để giải thích làm thế nào điều này làm cho nó một hệ thống 'decoupled', cho liên kết này. Gợi ý: Bạn có thể thấy khó. Ngoài ra, trừ khi bạn nghĩ rằng người đọc sẽ vui vẻ chấp nhận họ đã tính toán sai cả cuộc đời của họ, bạn có thể muốn giải thích tại sao các hành động đi qua Bộ điều khiển đầu tiên trong MVC mặc dù người dùng tương tác với các yếu tố 'trực quan' trên màn hình (tức là Xem), không phải một số lớp trừu tượng nằm sau chế biến. - Ash
Đây sẽ là câu trả lời được chấp nhận. rõ ràng và súc tích - Nelson Ramirez


  • MVP = Model-View-Người trình bày
  • MVC = Model-View-Controller

    1. Cả hai mẫu trình bày. Chúng tách biệt các phụ thuộc giữa một Model (nghĩ các đối tượng Domain), màn hình / trang web của bạn (View), và cách UI của bạn hoạt động như thế nào (Presenter / Controller)
    2. Họ là khá giống nhau trong khái niệm, folks khởi tạo Presenter / Controller khác nhau tùy thuộc vào khẩu vị.
    3. Một bài viết tuyệt vời về sự khác biệt là đây. Đáng chú ý nhất là mẫu MVC có Model cập nhật View.

31
2017-08-08 05:55



Mô hình cập nhật VIew. Và điều này vẫn là một hệ thống tách rời? - Ash


Cũng đáng nhớ là có nhiều loại MVP khác nhau. Fowler đã phá vỡ mô hình thành hai - Passive View và Supervising Controller.

Khi sử dụng Chế độ xem thụ động, Chế độ xem của bạn thường thực hiện giao diện chi tiết với các thuộc tính ánh xạ trực tiếp nhiều hơn hoặc ít hơn cho tiện ích con giao diện người dùng underlaying. Ví dụ: bạn có thể có ICustomerView với các thuộc tính như Tên và Địa chỉ.

Việc triển khai của bạn có thể trông giống như sau:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Lớp Presenter của bạn sẽ nói chuyện với mô hình và "ánh xạ" nó vào khung nhìn. Cách tiếp cận này được gọi là "Passive View". Lợi ích là chế độ xem dễ kiểm tra và dễ di chuyển giữa các nền tảng giao diện người dùng (Web, Windows / XAML, v.v.). Điểm bất lợi là bạn không thể tận dụng những thứ như databinding (đó là có thật không mạnh mẽ trong các khung như WPF và Silverlight).

Hương vị thứ hai của MVP là Bộ điều khiển giám sát. Trong trường hợp đó, Chế độ xem của bạn có thể có thuộc tính được gọi là Khách hàng, mà sau đó lại là databound cho các tiện ích con giao diện người dùng. Bạn không cần phải suy nghĩ về việc đồng bộ hóa và quản lý vi mô chế độ xem và Trình điều khiển giám sát có thể tham gia và trợ giúp khi cần, ví dụ với logic tương tác được biên dịch.

"Hương vị" thứ ba của MVP (hoặc có lẽ ai đó gọi nó là một mẫu riêng) là Mô hình Trình bày (hoặc đôi khi được gọi là Model-View-ViewModel). So với MVP bạn "hợp nhất" M và P thành một lớp. Bạn có đối tượng khách hàng của mình mà các tiện ích con giao diện người dùng của bạn là dữ liệu bị ràng buộc, nhưng bạn cũng có các trường giao diện người dùng bổ sung như "IsButtonEnabled" hoặc "IsReadOnly", v.v.

Tôi nghĩ rằng tài nguyên tốt nhất mà tôi đã tìm thấy cho kiến ​​trúc giao diện người dùng là hàng loạt bài đăng trên blog được thực hiện bởi Jeremy Miller qua tại Xây dựng bảng mục lục CAB của riêng bạn. Ông đã trình bày tất cả các hương vị của MVP và cho thấy mã C # để triển khai chúng.

Tôi cũng đã viết blog về mô hình Model-View-ViewModel trong bối cảnh Silverlight qua tại YouCard Re-visited: Triển khai mẫu ViewModel.


31
2018-04-06 13:51





Có rất nhiều câu trả lời cho câu hỏi, nhưng tôi cảm thấy cần phải có một câu trả lời thực sự đơn giản rõ ràng so sánh hai câu hỏi đó. Đây là cuộc thảo luận tôi đã tạo khi người dùng tìm kiếm tên phim trong ứng dụng MVP và MVC:

Người dùng: Nhấp vào nhấp chuột…

Lượt xem: Ai đó? [MVP|MVC]

Người dùng: Tôi chỉ cần nhấp vào nút tìm kiếm…

Lượt xem: Ok, đợi một chút…. [MVP|MVC]

( Lượt xem gọi điện thoại Người trình bày|Bộ điều khiển …) [MVP|MVC]

Lượt xem: Chào Người trình bày|Bộ điều khiển, Người dùng vừa mới nhấp vào nút tìm kiếm, tôi phải làm gì? [MVP|MVC]

Người trình bày|Bộ điều khiển: Chào Lượt xem, có bất kỳ cụm từ tìm kiếm nào trên trang đó không? [MVP|MVC]

Lượt xem: Vâng,… ở đây là… “piano” [MVP|MVC]

Người trình bày: Cảm ơn Lượt xem,… Trong khi đó tôi đang tìm kiếm cụm từ tìm kiếm trên Mô hình, hãy cho anh ấy xem một thanh tiến trình [MVP|MVC]

( Người trình bày|Bộ điều khiển đang gọi Mô hình …) [MVP|MVC]

Người trình bày|Bộ điều khiển: Chào Mô hình, Bạn có bất kỳ đối sánh nào cho cụm từ tìm kiếm này không ?: "piano" [MVP|MVC]

Mô hình: Chào Người trình bày|Bộ điều khiển, để tôi kiểm tra … [MVP|MVC]

( Mô hình đang tạo truy vấn tới cơ sở dữ liệu phim…) [MVP|MVC]

( Sau một lúc ... )

-------------- Đây là nơi MVP và MVC bắt đầu phân kỳ ---------------

Mô hình: Tôi đã tìm thấy một danh sách cho bạn, Người trình bày, ở đây là JSON “[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [MVP]

Mô hình: Có một số kết quả có sẵn, Bộ điều khiển. Tôi đã tạo ra một biến trường trong ví dụ của tôi và điền nó với kết quả. Tên của nó là "searchResultsList" [MVC]

(Người trình bày|Bộ điều khiển cảm ơn Mô hình và trở lại Lượt xem) [MVP|MVC]

Người trình bày: Cám ơn đã chờ đợi Lượt xem, Tôi tìm thấy một danh sách các kết quả phù hợp cho bạn và sắp xếp chúng theo một định dạng có thể trình bày: ["Piano Teacher 2001", "Piano 1993"]. Vui lòng hiển thị cho người dùng trong danh sách theo chiều dọc. Ngoài ra, hãy ẩn thanh tiến trình ngay bây giờ [MVP]

Bộ điều khiển: Cám ơn đã chờ đợi Lượt xem, Tôi đã hỏi Mô hình về truy vấn tìm kiếm của bạn. Nó nói nó đã tìm thấy một danh sách các kết quả phù hợp và lưu chúng trong một biến có tên là "searchResultsList" bên trong thể hiện của nó. Bạn có thể lấy nó từ đó. Ngoài ra, hãy ẩn thanh tiến trình ngay bây giờ [MVC]

Lượt xem: Cảm ơn nhiều Người trình bày [MVP]

Lượt xem: Cảm ơn bạn "Bộ điều khiển" [MVC] (Bây giờ là Lượt xem đang đặt câu hỏi: Tôi nên trình bày kết quả như thế nào từ Mô hình cho người dùng? Nên năm sản xuất của bộ phim đến trước hay cuối ...? Nó có nên nằm trong danh sách theo chiều dọc hay ngang không? ...)

Trong trường hợp bạn quan tâm, tôi đã viết một loạt các bài báo về các mẫu kiến ​​trúc ứng dụng (MVC, MVP, MVVP, kiến ​​trúc sạch, ...) kèm theo một repo Github đây. Mặc dù mẫu được viết cho android, các nguyên tắc cơ bản có thể được áp dụng cho bất kỳ phương tiện nào.


18
2017-08-05 10:20