en el patrón de diseño MVC/MVP/MVPC ¿dónde coloca su lógica comercial? No, no me refiero a ASP.NET MVC Framework (también conocido como "Tag Soup").en MVC/MVP/MVPC ¿dónde ubicas tu lógica comercial?
Algunas personas dicen que debes ponerlo en el "Controlador" en MVC/MVPC o "Presentador". Pero, otros piensan que debería ser parte del Modelo.
¿Qué piensas y por qué?
Esto es cómo lo veo:
El controlador es para lógica de la aplicación; lógica que es específica de cómo su aplicación quiere interactuar con el dominio del conocimiento al que pertenece.
El modelo es para la lógica que es independiente de la aplicación. es decir, lógica que es válida en todas las aplicaciones posibles del dominio del conocimiento al que pertenece.
Por lo tanto, casi todas las reglas comerciales estarán en el modelo.
Encuentro una pregunta útil para preguntarme cuándo tengo que decidir dónde poner algo de lógica: "¿Esto es siempre cierto, o solo para la parte de la aplicación que estoy codificando actualmente?"
+1: la interfaz de usuario es Ver/Controlador: cambia. El modelo es la esencia. –
Creo que esto es bueno. –
No creo que pertenezca al controlador, porque una vez que está incrustado allí no puede salir.
Creo que MVC debería tener otra capa inyectada en el medio: una capa de servicio que se asigna a casos de uso. Contiene lógica de negocios, sabe de unidades de trabajo y transacciones, y trata con objetos modelo y de persistencia para cumplir sus tareas.
El controlador tiene una referencia al servicio que necesita para cumplir con su caso de uso. Se preocupa por desasignar solicitudes en objetos con los que el servicio puede ocuparse, llama al servicio y ordena la respuesta para enviar de vuelta a la vista.
Con esta disposición, el servicio se puede usar solo incluso sin el par controlador/vista. Puede ser un objeto local o remoto, empaquetado e implementado de la forma que desee, que el controlador maneje.
El controlador ahora se vincula más estrechamente a la vista. Después de todo, es probable que el controlador que usará para un escritorio sea diferente al de una aplicación web.
Creo que este diseño está más orientado al servicio.
Puedes ponerlo en dos lugares. El controlador y en la capa de presentación. Al tener algo de la lógica en la capa de Presentación, puede limitar el número de solicitudes a la arquitectura que agrega carga al sistema. Sí, tienes que codificar dos veces, pero a veces esto es lo que necesitas para una experiencia de usuario receptiva.
un poco me gusta lo que se ha dicho aquí (http://www.martinhunter.co.nz/articles/MVPC.pdf)
"Con MVPC, el componente presentador del modelo MVP se divide en dos componentes: el (lógica de control de vista) Presenta y controlador (lógica de control propósito abstracto). "
veo ese PDF como 'forzado' y artificial en el presentador de división y la lógica del controlador en el ejemplo dado. Encuentro la explicación dada en el http://aviadezra.blogspot.com/2008/06/mvpc-model-view-presenter-controller.html más apropiada donde los delegados de vista controlan de inmediato al presentador, y la GUI cambia con respecto a la acción ejecutados se encapsulan en los "métodos de cambio de UI relacionados con la acción" y se llaman después de que se haya realizado la acción. – zappan
FYI Moví el artículo al que se hace referencia aquí https://www.continuity.kiwi.nz/Content/Articles/MVPC.pdf Cheers Martin. – muszeo
La forma en que tengo mi ASP.NET estructura de la aplicación MVC el flujo de trabajo es el siguiente:
Controlador -> Servicios -> Repositorios
la capa de servicios de arriba es donde toda la lógica de negocio se lleva a cabo. Si coloca su lógica de negocios en su capa de Controlador, perderá la capacidad de reutilizar esa lógica comercial en otros controladores.
Ojalá pudiera votar esto más ... Hago lo mismo. – Martin
@Kevin Cuando dice Capa de servicios, ¿se refiere literalmente a SOA como algo como WCF/servicios de datos/etc.? ¿O está implementado como solo más códigos/clases que se encuentran entre su controlador y repositorio? – AaronLS
@AaronLS Quiero decir simplemente otro proyecto que se encuentra entre mi controlador y mi repositorio. –
Por el amor de Dios, ponlo en el modelo !!!!!
Por supuesto, parte de la interacción del usuario tendrá que estar en la vista, que estará relacionada con su aplicación y lógica comercial, pero evite esto tanto como sea posible. Irónicamente, siguiendo el principio de hacer tan poco como sea posible, ya que el usuario está 'trabajando' en su GUI y tanto durante 'enviar' o las solicitudes de acción hacen que sea mejor para el usuario, y no al revés. Al menos para aplicaciones de línea de negocio.
Ponga su lógica de negocio en el dominio y mantenga su dominio por separado. Preferí Presenter -> Command (Comando de mensaje use NServiceBus) -> Dominio (con BC Bounded Context) -> EventStore -> Manejador de eventos -> Repository (modelo de lectura). Si la lógica no encaja en el dominio, utiliza la capa de servicio.
Lea el artículo de Martin Fowler, Eric Evan, Greg Young y Udi dahan. Han definido una imagen muy clara.
Aquí es el artículo escrito por Mark Nijhof: http://elegantcode.com/2009/11/11/cqrs-la-greg-young/
+1 para un artículo excelente –
El enlace al artículo ya no existe. – Celdor
@Celdor utilice web.archive.org - https://web.archive.org/web/20100124174150/http://elegantcode.com:80/2009/11/11/cqrs-la-greg-young/ –
En mi opinión su pregunta no se encuentra un poco de contexto. ¿Quiere decir MVC como un patrón de aplicación amplia o como un patrón de interfaz de usuario? – Rookian