MVP và MVC là gì và sự khác biệt là gì?

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

1. Những vấn đề nào làm cho 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?

Model-View-Presenter

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

MVP có xu hướng là một mô hình rất tự nhiên để đạt được sự trình bày riêng biệt trong Biểu mẫu web. Lý do là View luôn được tạo trước bởi thời gian chạy ASP.NET. 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 ngu ngốc càng tốt và chứa logic gần như bằng không. Người thuyết trình là một người trung gian nói chuyện với Người xem và Người mẫu. Chế độ xem và Mô hình được bảo vệ hoàn toàn với nhau. Mô hình có thể tăng các sự kiện, nhưng Người thuyết trình đăng ký chúng để 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à Người trình bày sử dụng để đặt dữ liệu. Tất cả trạng thái được quản lý trong Người thuyết trình chứ không phải Chế độ xem.

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

Bộ điều khiển giám sát: Người thuyết trình xử lý cử chỉ của người dùng. Khung nhìn liên kết với Mô hình trực tiếp thông qua liên kết dữ liệu. Trong trường hợp này, công việc của Người trình bày là chuyển Mô hình sang Chế độ xem để có thể liên kết với Mô hình đó. Người thuyết trình 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 cơ sở dữ liệu, số lượng mã được giảm.
• Con: có bề mặt ít kiểm tra hơn (vì liên kết dữ liệu) và có ít đóng gói hơn trong Chế độ xem vì nó nói chuyện trực tiếp với Mô hình.

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

Trong MVC , Bộ điều khiển chịu trách nhiệm xác định Chế độ xem nào sẽ hiển thị để đáp ứng vớ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 hành động chuyển qua Chế độ xem đến Người thuyết trình. Trong MVC, mọi hành động trong Chế độ xem tương quan với lệnh gọi Bộ điều khiển cùng với một hành động. Trong trang 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 có Trình điều khiển phản hồi. Khi Bộ điều khiển đó đã hoàn tất quá trình xử lý, 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 cho Bộ điều khiển
        -> Bộ điều khiển Logic
        -> Bộ điều khiển trả về Chế độ xem.

Một điểm khác biệt lớn khác về MVC là Chế độ xem không liên kết trực tiếp với Mô hình. Chế độ xem chỉ đơn giản là hiển thị và hoàn toàn không trạng thái. Trong triển khai MVC, View thường sẽ không có logic nào trong mã phía sau. Điều này trái với MVP khi nó thực sự cần thiết bởi vì, nếu Chế độ xem không ủy quyền cho Người thuyết trình, 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àymẫu. Trong mô hình này không có Người trình bày. Thay vào đó, View 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 chế 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à người ta sẽ không bao giờ đưa vào mô hình miền vì nó sẽ vi phạm các mối quan tâm riêng 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. 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à về cơ bản bạn có thể loại bỏ hoàn toàn mã phía sau vì PM hoàn toàn gói gọn tất cả các hành vi cho chế độ xem.Model-View-ViewModel .

Có 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 (Lăng kính cũ) về các mẫu trình bày tách biệt

Đây là 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 nghĩ về sự khác biệt giữa hai loại.

MVC

MVP

Tôi đã viết về điều này một thời gian trước, trích dẫn trên bài viết xuất sắc của Todd Snyder về sự khác biệt giữa hai :

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

Mô hình MVP

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

Mô hình MVC

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

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

Dưới đây là minh họa đại diện cho lưu lượng truyền thông

MVP không nhất thiết là một kịch bản mà Chế độ xem chịu trách nhiệm (ví dụ xem MVP của Taligent).
Tôi thấy thật đáng tiếc khi 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) trái ngược với một mô hình chống đối vì nó mâu thuẫn với "Đó chỉ là một quan điểm" (Lập trình viên thực dụng). "Đây chỉ là một chế độ xem" nói rằng chế độ xem cuối cùng được hiển thị cho người dùng là mối quan tâm thứ yếu của ứng dụng. Mẫu MVP của Microsoft tái hiện việc sử dụng lại Lượt xem khó khăn hơn nhiều và thuận tiện cho nhà thiết kế của Microsoft không khuyến khích thực hành xấu.

Thành thật mà nói, tôi nghĩ rằng mối quan tâm cơ bản của MVC là đúng đối với bất kỳ triển khai MVP nào và sự khác biệt gần như hoàn toàn về ngữ nghĩa. Miễn là bạn đang theo dõi 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à kiểm soát tương tác người dùng) và mô hình (dữ liệu cơ bản và / hoặc dịch vụ)) 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 liệu mô hình của bạn là MVC, MVP hay Trình điều khiển giám sát? Mẫu thực duy nhất vẫn là MVC, phần còn lại chỉ là các hương vị khác nhau của nó.

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

Cá nhân tôi nghĩ rằng MVP chỉ mới được giới thiệu lại gần đây như một thuật ngữ hấp dẫn để giảm bớt tranh luận giữa những người khổng lồ ngữ nghĩa, người tranh luận liệu có thứ 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. Cả hai lý do này trong các cuốn sách của tôi đều chứng minh sự tồn tại của nó như là một mẫu thiết kế riêng biệt.

MVP: xem là 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à thao tác chế độ xem 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 người trình bày hay bạn muốn chế độ xem có các sự kiện mà người trình bày lắng nghe? Nó hiểu rõ điều này: Quan điểm biết về người trình bày. Các đại biểu xem 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 phù hợp và tương tác với mô hình để tiếp tục định cấu hình chế độ xem. Nó nắm rõ: bộ điều khiển tạo và quản lý khung nhìn; khung nhìn là nô lệ cho bộ điều khiển. Chế độ xem không biết về bộ điều khiển.

MVC (Model View Controller)

Đầu vào được hướng vào Bộ điều khiển trước, không phải dạng xem. Đầu vào đó có thể đến từ người dùng tương tác với một trang, nhưng cũng có thể là từ việc chỉ cần nhập một url cụ thể vào trình duyệt. Trong cả hai trường hợp, Bộ điều khiển của nó được giao tiếp để khởi động một số chức năng. Có một mối quan hệ nhiều-một giữa Bộ điều khiển và Chế độ xem. Đó 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 thao tác được thực thi. Lưu ý mũi tên một chiều từ Bộ điều khiển để 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 trả lại Mô hình, do đó, có kiến ​​thức giữa Chế độ xem và Mô hình dự kiến ​​được truyền vào Mô hình, nhưng không phải Bộ điều khiển phục vụ nó.

MVP (Người dẫn chương trình xem mẫu)

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

Để tham khảo thêm

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 có một câu trả lời thực sự đơn giản so sánh rõ ràng giữa 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 vào

Xem : Ai vậy? [ MVP | MVC ]

Thành viên: Tôi vừa bấm vào nút tìm kiếm

Xem : Ok, chờ một giây. [ MVP | MVC ]

( Xem gọi người thuyết trình | Trình điều khiển từ khóa ) [ MVP | MVC ]

Xem : Hey Người thuyết trình | Trình điều khiển , một Người dùng vừa 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 | Trình điều khiển : Hey View , có bất kỳ thuật ngữ tìm kiếm nào trên trang đó không? [ MVP | MVC ]

Xem : Có, ở đây là làng piano piano [ MVP | MVC ]

Người dẫn chương trình : Cảm ơn Chế độ xem , khi đó tôi đang tìm kiếm cụm từ tìm kiếm trên Mô hình , vui lòng chỉ cho anh ấy / cô ấy một thanh tiến trình [ MVP | MVC ]

( Người thuyết trình | Trình điều khiển đang gọi Model Model ) [ MVP | MVC ]

Người trình bày | Điều khiển : Hey mẫu , Bạn có bất cứ trận đấu cụm từ tìm kiếm này ?: “piano” [ MVP | MVC ]

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

( Người mẫu đang thực hiện truy vấn cơ sở dữ liệu phim ') [ MVP | MVC ]

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

-------------- Đây là lúc 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à trong 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 một biến trường trong ví dụ của mình và điền vào kết quả. Tên của nó là "searchResultsList" [ MVC ]

( Người thuyết trình | Trình điều khiển cảm ơn Người mẫu và quay lại Chế độ xem ) [ MVP | MVC ]

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

Trình điều khiển : Cảm ơn vì đã chờ Xem , tôi đã hỏi Model về truy vấn tìm kiếm của bạn. Nó nói rằng nó đã tìm thấy một danh sách các kết quả phù hợp và lưu trữ 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, vui lòng ẩn thanh tiến trình ngay bây giờ [ MVC ]

Xem : Cảm ơn bạn rất nhiều Người trình bày [ MVP ]

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

Trong trường hợp bạn quan tâm, tôi đã viết một loạt bài viết liên quan đến các mẫu kiến ​​trúc ứng dụng (MVC, MVP, MVVP, kiến ​​trúc sạch, ...) kèm theo repo Github tại đâ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.

• MVP = Model-View-Presenter

• MVC = Model-View-Controller

  1. Cả hai mẫu trình bày. Chúng phân tách các phụ thuộc giữa một Mô hình (nghĩ các đối tượng Miền), màn hình / trang web của bạn (Chế độ xem) và giao diện người dùng của bạn được cho là hành xử (Người trình bày / Trình điều khiển)
  2. Chúng khá giống nhau về khái niệm, mọi người khởi tạo Người thuyết trình / Người điều khiển khác nhau tùy theo sở thích.
  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.

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

MVC là một mẫu cho kiến ​​trúc của một ứng dụng phần mềm. Nó tách logic ứng dụng thành ba phần riêng biệt, thúc đẩy tính mô đun và dễ dàng hợp tác và tái sử dụng. Nó cũng làm cho các ứng dụng linh hoạt hơn và chào đón các lần lặp. Nó tách một ứng dụng thành các thành phần sau:

• Mô hình xử lý dữ liệu và logic nghiệp vụ
• Bộ điều khiển để xử lý giao diện người dùng và ứng dụng
• Lượt xem để xử lý các đối tượng giao diện đồ họa và trình bày

Để làm cho điều này rõ ràng hơn một chút, hãy tưởng tượng một ứng dụng danh sách mua sắm đơn giản. Tất cả những gì chúng tôi muốn là một danh sách tên, số lượng và giá của từng mặt hàng chúng tôi cần mua trong tuần này. Dưới đây chúng tôi sẽ mô tả cách chúng tôi có thể thực hiện một số chức năng này bằng cách sử dụng MVC.

Model-View-Presenter

• Các mô hình là dữ liệu sẽ được hiển thị trong giao diện (giao diện người dùng).
• Khung nhìn là một giao diện hiển thị dữ liệu (mô hình) và định tuyến các lệnh người dùng (sự kiện) đến Người trình bày để hành động theo dữ liệu đó. Khung nhìn thường có một tham chiếu đến Người trình bày của nó.
• Người thuyết trình là người trung gian của người Hồi giáo (được chơi bởi bộ điều khiển trong MVC) và có các tham chiếu đến cả, chế độ xem và mô hình. Xin lưu ý rằng từ mô hình mô hình trực tuyến là sai lệch. Nó nên là logic kinh doanh lấy hoặc thao tác một Mô hình . Ví dụ: Nếu bạn có cơ sở dữ liệu lưu trữ Người dùng trong bảng cơ sở dữ liệu và Chế độ xem của bạn muốn hiển thị danh sách người dùng, thì Người thuyết trình sẽ có một tham chiếu đến logic nghiệp vụ cơ sở dữ liệu của bạn (như DAO) từ đó Người trình bày sẽ truy vấn danh sách của người dùng.

Nếu bạn muốn xem một mẫu với cách thực hiện đơn giản, vui lòng kiểm tra bài đăng GitHub này

Một quy trình cụ thể của truy vấn và hiển thị danh sách người dùng từ cơ sở dữ liệu có thể hoạt động như thế này:

Sự khác biệt giữa các mẫu MVC và MVP là gì?

Mô hình MVC

• Trình điều khiển dựa trên các hành vi và có thể được chia sẻ qua các lượt xem

• Có thể chịu trách nhiệm xác định chế độ xem nào sẽ hiển thị (Mẫu điều khiển trước)

Mô hình MVP

• View được kết nối lỏng lẻo hơn với mô hình. Người trình bày có trách nhiệm ràng buộc mô hình với khung nhìn.

• Kiểm tra đơn vị dễ dàng hơn vì tương tác với chế độ xem thông qua giao diện

• Thường xem để trình bày bản đồ một đến một. Quan điểm phức tạp có thể có nhiều người thuyết trình.

Cũng đáng nhớ là có nhiều loại MVP khác nhau. Fowler đã chia mô hình thành hai - Chế độ xem thụ động và điều khiển giám sát.

Khi sử dụng Chế độ xem thụ động, Chế độ xem của bạn thường triển khai giao diện chi tiết với các thuộc tính ánh xạ trực tiếp ít nhiều đến tiện ích UI bên dưới. Chẳng hạn, bạn có thể có một 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ư thế này:

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

Lớp Người thuyết trình của bạn sẽ nói chuyện với mô hình và "ánh xạ" nó tới khung nhìn. Cách tiếp cận này được gọi là "Chế độ xem thụ động". Lợi ích là chế độ xem dễ kiểm tra và việc di chuyển giữa các nền tảng UI (Web, Windows / XAML, v.v.) dễ dàng hơn. Nhược điểm là bạn không thể tận dụng những thứ như databinding (vốn thực sự 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ó một thuộc tính được gọi là Khách hàng, sau đó một lần nữa là cơ sở dữ liệu cho các tiện ích UI. Bạn không phải suy nghĩ về việc đồng bộ hóa và quản lý vi mô chế độ xem và Bộ điều khiển giám sát có thể bước vào và trợ giúp khi cần, ví dụ như với logic tương tác được biên dịch.

"Hương vị" thứ ba của MVP (hoặc ai đó có lẽ sẽ 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 mà các widget UI của bạn bị ràng buộc với dữ liệu, nhưng bạn cũng có các trường spesific UI bổ sung như "IsButtonEnables" 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 UI là một loạt các bài đăng trên blog được thực hiện bởi Jeremy Miller tại Mục lục sê-ri CAB của chính bạn . Ông đã bao gồm tất cả các hương vị của MVP và hiển thị mã C # để thực hiện chúng.

Tôi cũng đã viết blog về mẫu Model-View-ViewModel trong bối cảnh Silverlight trên tại YouCard đã truy cập lại: Triển khai mẫu ViewModel .

Chúng từng giải quyết các vấn đề khác nhau và thậm chí có thể được kết hợp với nhau để có một cái gì đó như dưới đây

Ngoài ra còn có một so sánh đầy đủ về MVC, MVP và MVVM tại đây

Cả hai khung này đều nhằm mục đích ngăn cách các mối quan tâm - ví dụ: tương tác với nguồn dữ liệu (mô hình), logic ứng dụng (hoặc biến dữ liệu này thành thông tin hữu ích) (Trình điều khiển / Người trình bày) và mã hiển thị (Chế độ xem). Trong một số trường hợp, mô hình cũng có thể được sử dụng để biến nguồn dữ liệu thành mức độ trừu tượng cao hơn. Một ví dụ điển hình của việc này là dự án MVC Storefront .

Có một cuộc thảo luận ở đây liên quan đến sự khác biệt giữa MVC và MVP.

Sự khác biệt được đưa ra là trong một ứng dụng MVC theo truyền thống có khung nhìn và bộ điều khiển tương tác với mô hình, nhưng không tương tác với nhau.

Thiết kế MVP có Người trình bày truy cập mô hình và tương tác với chế độ xem.

Phải nói rằng, ASP.NET MVC theo các định nghĩa này là một khung MVP vì Bộ điều khiển truy cập Mô hình để điền vào Chế độ xem có nghĩa là không có logic (chỉ hiển thị các biến do Bộ điều khiển cung cấp).

Để có thể có ý tưởng về sự khác biệt của ASP.NET MVC từ MVP, hãy xem bài trình bày MIX này của Scott Hanselman.

Cả hai đều là các mẫu cố gắng tách biệt trình bày và logic kinh doanh, tách riêng logic kinh doanh khỏi các khía cạnh UI

Về mặt kiến ​​trúc, MVP là cách tiếp cận dựa trên Trình điều khiển trang trong đó MVC là cách tiếp cận dựa trên Trình điều khiển trước. Điều đó có nghĩa là trong vòng đời trang web mẫu tiêu chuẩn MVP chỉ được tăng cường bằng cách trích xuất logic nghiệp vụ từ mã phía sau. Nói cách khác, trang là một yêu cầu http phục vụ. Nói cách khác, MVP IMHO là loại hình tăng cường tiến hóa. Mặt khác, MVC thay đổi hoàn toàn trò chơi vì yêu cầu bị chặn bởi lớp trình điều khiển trước khi trang được tải, logic nghiệp vụ được thực thi ở đó và sau đó kết quả cuối cùng là bộ điều khiển xử lý dữ liệu vừa được đổ vào trang ("view") ý nghĩa, MVC trông (ít nhất là với tôi) rất nhiều để hương vị Bộ điều khiển giám sát của MVP được tăng cường với công cụ định tuyến

Cả hai đều cho phép TDD và có những nhược điểm và nhược điểm.

Quyết định về cách chọn một trong số họ IMHO phải dựa trên thời gian một người đầu tư vào loại hình phát triển web dạng web NET NET. Nếu một người cho rằng mình tốt trong các hình thức web, tôi sẽ đề xuất MVP. Nếu ai đó cảm thấy không thoải mái trong những thứ như vòng đời trang, thì MVC có thể là một cách để đi đến đây.

Đây là một liên kết bài đăng blog khác cung cấp thêm một chút chi tiết về chủ đề này

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controll-mvc.aspx

Tôi đã sử dụng cả MVP và MVC và mặc dù chúng tôi với tư cách là nhà phát triển có xu hướng tập trung vào sự khác biệt kỹ thuật của cả hai mẫu, điểm cho MVP trong IMHO liên quan nhiều đến việc dễ dàng chấp nhận hơn bất kỳ điều gì khác.

Nếu tôi đang làm việc trong một nhóm đã có nền tảng tốt về phong cách phát triển biểu mẫu web thì việc giới thiệu MVP sẽ dễ dàng hơn nhiều so với MVC. Tôi sẽ nói rằng MVP trong kịch bản này là một chiến thắng nhanh chóng.

Kinh nghiệm của tôi cho tôi biết rằng việc chuyển một nhóm từ các biểu mẫu web sang MVP và sau đó từ MVP sang MVC là tương đối dễ dàng; chuyển từ các hình thức web sang MVC là khó khăn hơn.

Tôi để lại ở đây một liên kết đến một loạt các bài viết mà một người bạn của tôi đã xuất bản về MVP và MVC.

http://www.qsoft.be/post/BuILD-the-MVP-StoreFront-Gutthrie-style.aspx

Trong MVP, khung nhìn lấy dữ liệu từ người trình bày để vẽ và chuẩn bị / chuẩn hóa dữ liệu từ mô hình trong khi trong MVC, bộ điều khiển lấy dữ liệu từ mô hình và đặt, bằng cách ấn vào khung nhìn.

Trong MVP, bạn có thể có một chế độ xem làm việc với nhiều loại người thuyết trình và một người thuyết trình duy nhất làm việc với nhiều chế độ xem khác nhau.

MVP thường sử dụng một số loại khung liên kết, chẳng hạn như khung ràng buộc Microsoft WPF hoặc các khung liên kết khác nhau cho HTML5 và Java.

Trong các khung đó, UI / HTML5 / XAML, nhận thức được thuộc tính nào của người trình bày mà mỗi phần tử UI hiển thị, vì vậy khi bạn liên kết một khung nhìn với người trình bày, khung nhìn sẽ tìm các thuộc tính và biết cách vẽ dữ liệu từ chúng và cách để đặt chúng khi người dùng thay đổi giá trị trong UI.

Vì vậy, nếu ví dụ, mô hình là một chiếc xe hơi, thì người trình bày là một loại người trình bày xe hơi, để lộ các thuộc tính xe hơi (năm, nhà sản xuất, ghế ngồi, v.v.) để xem. Chế độ xem biết rằng trường văn bản có tên 'nhà sản xuất ô tô' cần hiển thị thuộc tính của người thuyết trình.

Sau đó, bạn có thể liên kết với chế độ xem nhiều loại người thuyết trình khác nhau, tất cả đều phải có thuộc tính Maker - đó có thể là máy bay, tàu hỏa hoặc bất cứ điều gì, chế độ xem không quan tâm. Khung nhìn rút ra dữ liệu từ người trình bày - bất kể đó là gì - miễn là nó thực hiện giao diện đã thỏa thuận.

Khung ràng buộc này, nếu bạn gỡ nó xuống, nó thực sự là bộ điều khiển :-)

Và vì vậy, bạn có thể xem MVP như một sự phát triển của MVC.

MVC là tuyệt vời, nhưng vấn đề là thường bộ điều khiển của nó cho mỗi lượt xem. Bộ điều khiển A biết cách đặt các trường của Chế độ A. Nếu bây giờ, bạn muốn Xem A để hiển thị dữ liệu của mô hình B, bạn cần Bộ điều khiển A để biết mô hình B hoặc bạn cần Bộ điều khiển A để nhận một đối tượng có giao diện - giống như MVP chỉ không có các ràng buộc hoặc bạn cần viết lại mã bộ UI trong Bộ điều khiển B.

Kết luận - MVP và MVC đều tách rời các mẫu UI, nhưng MVP thường sử dụng khung liên kết là MVC bên dưới. THUS MVP ở cấp độ kiến ​​trúc cao hơn MVC và mẫu bao bọc phía trên MVC.

Cái nhìn ngắn gọn khiêm tốn của tôi: MVP dành cho quy mô lớn và MVC cho quy mô nhỏ. Với MVC, đôi khi tôi cảm thấy V và C có thể được nhìn thấy hai mặt của một thành phần không thể tách rời duy nhất liên kết trực tiếp với M, và một thứ chắc chắn rơi vào điều này khi đi xuống đến các thang đo ngắn hơn, như các điều khiển UI và các widget cơ sở. Ở mức độ chi tiết này, MVP không có ý nghĩa gì. Khi một người đi ngược lại với quy mô lớn hơn, giao diện phù hợp trở nên quan trọng hơn, tương tự với sự phân công trách nhiệm rõ ràng và đến đây là MVP.

Mặt khác, quy tắc ngón tay cái này, có thể có trọng lượng rất nhỏ khi các đặc điểm nền tảng ủng hộ một số loại quan hệ giữa các thành phần, như với web, nơi có vẻ dễ thực hiện MVC hơn, so với MVP.

Tôi nghĩ hình ảnh này của Erwin Vandervalk (và bài viết kèm theo ) là lời giải thích tốt nhất về MVC, MVP và MVVM, những điểm tương đồng và sự khác biệt của chúng. Các bài viết không hiển thị trong kết quả công cụ tìm kiếm cho các truy vấn trên "MVC, MVP, và MVVM" vì tiêu đề của bài viết không chứa dòng chữ "MVC" và "MVP"; nhưng đó là lời giải thích tốt nhất, tôi nghĩ vậy

( Bài viết cũng phù hợp với những gì chú Bob Martin đã nói trong một trong những cuộc nói chuyện của mình: rằng MVC ban đầu được thiết kế cho các thành phần UI nhỏ, không dành cho kiến ​​trúc của hệ thống)

Có nhiều phiên bản của MVC, câu trả lời này là về MVC gốc trong Smalltalk. Tóm lại, nó là

Bài nói chuyện này droidcon NYC 2017 - Thiết kế ứng dụng sạch với Architecture Components làm rõ nó

Có này đoạn video đẹp từ Bác Bob nơi ông một thời gian ngắn giải thích MVC & MVP ở cuối.

IMO, MVP là phiên bản cải tiến của MVC, về cơ bản bạn tách biệt mối quan tâm về những gì bạn sẽ hiển thị (dữ liệu) khỏi cách bạn sẽ hiển thị (chế độ xem). Người trình bày bao gồm logic kinh doanh của giao diện người dùng của bạn, hoàn toàn áp đặt dữ liệu nào sẽ được trình bày và cung cấp cho bạn một danh sách các mô hình chế độ xem câm. Và khi đến lúc hiển thị dữ liệu, bạn chỉ cần cắm chế độ xem của mình (có thể bao gồm cùng một id) vào bộ điều hợp của bạn và đặt các trường xem có liên quan bằng cách sử dụng các mô hình chế độ xem đó với số lượng mã tối thiểu được giới thiệu (chỉ sử dụng setters). Lợi ích chính của nó là bạn có thể kiểm tra logic nghiệp vụ UI của mình dựa trên nhiều / nhiều chế độ xem khác nhau như hiển thị các mục trong danh sách ngang hoặc danh sách dọc.

Trong MVC, chúng ta nói chuyện thông qua các giao diện (ranh giới) để dán các lớp khác nhau. Bộ điều khiển là một bổ trợ cho kiến ​​trúc của chúng tôi nhưng nó không có giới hạn nào để áp đặt những gì cần hiển thị. Theo nghĩa đó, MVP là một loại MVC với khái niệm các khung nhìn có thể cắm vào bộ điều khiển trên các bộ điều hợp.

Tôi hy vọng điều này sẽ giúp tốt hơn.

Bạn đã quên về Phản hồi tên miền hành động ( ADR ).

Như đã giải thích trong một số đồ họa ở trên, có một mối quan hệ / liên kết trực tiếp giữa Mô hình và Chế độ xem trong MVC. Một hành động được thực hiện trên Bộ điều khiển , sẽ thực hiện một hành động trên Mô hình . Hành động đó trong Mô hình , sẽ kích hoạt phản ứng trong Chế độ xem . Các Xem , luôn được cập nhật khi các mẫu nhà nước 's thay đổi.

Một số người cứ quên, rằng MVC đã được tạo ra vào cuối năm 70 " và Web chỉ được tạo vào cuối 80" / đầu 90 ". MVC ban đầu không được tạo cho Web, nhưng thay vào đó là các ứng dụng Desktop, trong đó Trình điều khiển , Model và View sẽ cùng tồn tại.

Bởi vì chúng tôi sử dụng các khung web ( ví dụ: Laravel ) vẫn sử dụng các quy ước đặt tên giống nhau ( mô hình-khung nhìn-trình điều khiển ), chúng tôi có xu hướng nghĩ rằng đó phải là MVC, nhưng thực ra nó là một thứ khác.

Thay vào đó, hãy xem Hành động-Miền-Phản hồi . Trong ADR, Bộ điều khiển nhận một Hành động , sẽ thực hiện một thao tác trong Mô hình / Miền . Cho đến nay, giống nhau. Sự khác biệt là, sau đó nó thu thập của hoạt động đó phản ứng / dữ liệu, và vượt qua nó để một Responder ( ví dụ :.view() ) cho rendering. Khi một hành động mới được yêu cầu trên cùng một thành phần, Bộ điều khiển được gọi lại và chu trình sẽ lặp lại. Trong ADR, không có kết nối giữa Mô hình / Miền và Chế độ xem ( Phản hồi của Reponser ).

Lưu ý: Wikipedia nói rằng " Tuy nhiên, mỗi hành động ADR được thể hiện bằng các lớp hoặc đóng riêng biệt. ". Điều này không hẳn đúng. Một số Tác vụ có thể nằm trong cùng Bộ điều khiển và mẫu vẫn giống nhau.

mvc ngoại tình Bộ điều khiển xem mô hình phản hồi tên miền hành động

Câu trả lời đơn giản nhất là cách khung nhìn tương tác với mô hình. Trong MVP, chế độ xem được cập nhật bởi người trình bày, đóng vai trò trung gian giữa chế độ xem và mô hình. Người trình bày lấy đầu vào từ khung nhìn, lấy dữ liệu từ mô hình và sau đó thực hiện bất kỳ logic nghiệp vụ nào được yêu cầu và sau đó cập nhật khung nhìn. Trong MVC, mô hình cập nhật khung nhìn trực tiếp thay vì quay lại qua bộ điều khiển.

• Trong MVC, View có phần UI, bộ điều khiển là trung gian giữa view và model & model chứa logic nghiệp vụ.
• Trong MVP, View chứa cả UI và triển khai của người thuyết trình vì ở đây, người thuyết trình chỉ là một giao diện & mô hình giống nhau, tức là chứa logic nghiệp vụ.

MVP

MVP là viết tắt của Model - View- Presenter. Điều này đã xuất hiện vào đầu năm 2007 khi Microsoft giới thiệu các ứng dụng cửa sổ Smart Client.

Người thuyết trình đóng vai trò giám sát trong MVP ràng buộc Xem các sự kiện và logic kinh doanh từ các mô hình.

Liên kết xem sự kiện sẽ được triển khai trong Trình dẫn từ giao diện xem.

Khung nhìn là bộ khởi tạo cho đầu vào của người dùng và sau đó ủy thác các sự kiện cho Người trình bày và người trình bày xử lý các ràng buộc sự kiện và lấy dữ liệu từ các mô hình.

Ưu điểm: Chế độ xem chỉ có UI chứ không có bất kỳ logic nào Khả năng kiểm tra cao

Nhược điểm: Bit phức tạp và nhiều công việc hơn khi thực hiện các ràng buộc sự kiện

MVC

MVC là viết tắt của Model-View-Controller. Bộ điều khiển chịu trách nhiệm tạo các mô hình và hiển thị các khung nhìn với các mô hình ràng buộc.

Trình điều khiển là bộ khởi tạo và nó quyết định khung nhìn nào sẽ hiển thị.

Ưu điểm: Nhấn mạnh vào Nguyên tắc Trách nhiệm Đơn lẻ Mức độ kiểm tra cao

Nhược điểm: Đôi khi khối lượng công việc quá nhiều cho Bộ điều khiển, nếu cố gắng hiển thị nhiều chế độ xem trong cùng một bộ điều khiển.