MVP (Presentador de vista de modelo) o MVC (Controlador de vista de modelo)

Question

Ya conozco la diferencia entre MVP y MVC. Luego también, después de pasar por el SRS de una aplicación, obtengo una solución que se debe seleccionar, aplicar y seguir como Arquitectura de aplicación. Según mi entender, elegiría MVP cuando exista la posibilidad de utilizar la misma lógica de negocios, de más de 2 GUI. Me gusta para una aplicación con una parte pública (www) y Adming (winform). Si no hay tal ... busque MVC. Porque puedo seguir los patrones de fábrica con más precisión.

Dudes, no sé, pero siento que solo juego a ciegas si pudiera elegir entre ellos. Necesito saber. ¿Qué opinión tienen ustedes sobre esto?

Nota: Sigo .net y C#.

Answer 1

En mi mente las diferencias para todas las variaciones de los patrones Modelo Vista Controlador (MVP, Passive View, Supervising Controller, Ver Modelo, etc.) son muy sutiles. Se trata de quién procesa los datos y toma los datos de quién, realmente. Todos están tratando de resolver el mismo problema, separando algo de otra cosa,, y las soluciones hacen todo eso de manera similar.

Es casi claramente evidente que los conceptos son similares en su aplicación cuando se piensa en ello en términos visuales:

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 +------+ 

Son similares en que la jerarquía de clases puede parecer el mismo en ambos. La diferencia, sin embargo, son las diferentes maneras de mostrar y manipular datos. Cuando estás desplegando tu propio MVC, estás a cargo de cómo debería verse.

Realmente no importa mucho, ya que todos se basan en un principio de separar las partes de código en entidades lógicas independientes y reducir la duplicación de código. Siempre que mantenga el code coupling low, debería funcionar bien al final. Solo importa si quieres ser consecuentemente dogmático con la arquitectura de tu aplicación.

Sea pragmático al respecto y haga lo que mejor se adapte a sus necesidades ya que terminará con una mezcla de todos modos. Debería ser "bastante" fácil cambiar entre las variaciones según lo que necesite la vista. Siga los principios SOLID y debería hacerlo bien. (Ver también this about SOLID).

Le sugiero que investigue si hay marcos MVC o MVP para ver cómo se hace.

Answer 2

Creo que estás en el camino correcto aquí. El MVP para aplicaciones con más de una GUI y MVC para aplicaciones web es mi guía general. Si haces cualquiera de los dos, usaría un framework como ASP .Net MVC o Castle's MonoRail porque hacer las cañerías por tu cuenta puede ser un problema. Hay una buena implementación de referencia de MVC here basado en la base de datos Neptuno que se incluye con SQL Server 2000.

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