MVP (Model View Presenter) или MVC (Model View Controller) - PullRequest
7 голосов
/ 16 января 2010

Я уже знаю разницу между MVP и MVC. Затем, после прохождения SRS приложения, я получаю исправление, которое нужно выбрать, применить и использовать как архитектуру приложения. Насколько я понимаю, я бы выбрал MVP, где есть вероятность использования Same Business Logic, из более чем 2 GUI. Как для приложения с публичной (www) и Adming (winform) частью. Если нет такого ... ищите MVC. Потому что я могу более точно следовать заводским шаблонам.

Чувак, я не знаю, но я чувствую, что просто играю вслепую, если бы мне пришлось выбирать среди них. Мне нужно знать. Какое у вас мнение по этому поводу, ребята?

Примечание: я следую .net и C #.

Ответы [ 2 ]

17 голосов
/ 16 января 2010

На мой взгляд, различия для всех вариаций моделей контроллера представления модели ( MVP , Пассивное представление , Контролирующий контроллер , Просмотр модели, и т. Д. . ) довольно тонкие. Все дело в том, кто обрабатывает данные, а кто на самом деле получает данные. Все они пытаются решить одну и ту же проблему, отделяя что-то от другую вещь , и решения делают все это аналогичным образом.

Почти очевидно, что концепции похожи в реализации, когда вы думаете об этом в визуальных терминах:

Simplistic MVC:

+-------+       manipulates data
| Model |<---------------------+
+-------+                      |
    |                          |
    | gets data                |
    v                          |
+------------+ serves data  +------+
| Controller |------------->| View |
+------------+              +------+

Simplistic MVP:

+-------+
| Model |
+-------+
  |  ^
  |  | get/manipulates data
  v  |
+-----------+  serve data   +------+
| Presenter |-------------->| View |
|           |<--------------|      |
+-----------+  tell changes +------+

Они похожи в той иерархии классов, могут выглядеть одинаково в обеих. Разница, однако, заключается в разных способах отображения и манипулирования данными. Когда вы развертываете свой собственный MVC, вы отвечаете за то, как он должен выглядеть.

Это не имеет большого значения, поскольку все они основаны на принципе разделения частей кода на самообслуживаемые логические объекты и уменьшения дублирования кода. Пока вы сохраняете кодовое соединение низким , в конце концов, оно должно работать хорошо. Это имеет значение, только если вы хотите быть догматически последовательными с архитектурой вашего приложения.

Будьте прагматичны в этом и делайте то, что больше всего соответствует вашим потребностям, так как в любом случае вы получите микс. Должно быть «довольно» легко переключаться между вариантами в зависимости от того, что нужно представлению. Следуйте SOLID принципам, и у вас все будет хорошо. (См. Также о SOLID ).

Я бы посоветовал вам изучить, существуют ли инфраструктуры MVC или MVP, чтобы увидеть, как это делается.

1 голос
/ 16 января 2010

Я думаю, что вы на правильном пути. MVP для приложений с более чем одним графическим интерфейсом и MVC для веб-приложений - это мое общее руководство. Если вы сделаете один из них, я бы использовал такую ​​среду, как ASP .Net MVC или MonoRail Касла, потому что выполнение сантехники самостоятельно может быть проблемой. Существует хорошая эталонная реализация MVC здесь на основе базы данных Northwind, поставляемой с SQL Server 2000.

http://nsk.codeplex.com/SourceControl/list/changesets

...