asp.net-mvc - ventajas - mvc c#

¿Cómo estructurar una aplicación MVC empresarial y hacia dónde va Business Logic? (8)

Soy un novato de MVC. Por lo que yo puedo decir:

Controlador : se ocupa de las solicitudes de enrutamiento
Vista : se ocupa de la presentación de datos
Modelo : se parece mucho a una capa de acceso a datos

¿A dónde va la lógica de negocios?

Tome una aplicación empresarial grande con:

Varias fuentes de datos diferentes (WCF, WebServices y ADO) unidas en una capa de acceso a datos (que usa múltiples DTO diferentes).
Una gran lógica de negocios segmentada en varios dlls.

¿Cuál es una forma adecuada para que una aplicación web MVC se coloque en la parte superior de esto (en términos de código y estructura del proyecto)?

El ejemplo que he visto donde todo va en la carpeta Modelo no parece apropiado para aplicaciones muy grandes.

Gracias por cualquier consejo!

"Depende" :)

Las solicitudes se envían a los controladores, que las manejan de forma adecuada. Los controladores son el "pegamento" que contiene todo lo demás (Modelos, Vistas, etc.) juntos. Por lo tanto, es natural que la "lógica comercial" sea procesada directamente o descargada a otro componente por un controlador.

Donde realmente pones la lógica depende de tus necesidades. Si solo un controlador necesita la lógica, ponerla directamente dentro de uno está bien. Por supuesto, la lógica también puede entrar en un único modelo si es necesario para la coherencia de los datos.

Alternativamente, puede poner la lógica en clases / funciones auxiliares, o (como han mencionado otros), puede crear una capa de servicios para la lógica de negocios.

En mis aplicaciones, suelo crear un proyecto "Core" separado del proyecto web.

El proyecto principal contiene :

Objetos comerciales, como entidades y tal
Acceso a los datos
Cualquier cosa que no esté específicamente diseñada para la web

El proyecto web contiene :

Controladores , que enrutan las solicitudes desde la interfaz de usuario a la lógica del núcleo
Vistas , que se centran en presentar datos en HTML
Ver modelos , que aplanan / transforman objetos comerciales centrales en estructuras más simples diseñadas para soportar vistas específicas

El punto clave aquí es que la carpeta / espacio de nombres de Modelos basados en la web SÓLO se utiliza para modelos específicos de la presentación que documentan las variables específicas necesarias para una vista determinada. La mayor "lógica de negocios" posible entra en el proyecto central.

MVC no es una arquitectura completa para sus necesidades, solo cubre la capa de presentación. Sus controladores deben hablar con una capa empresarial y recuperar los objetos del Modelo. La capa empresarial puede hablar con otras capas, como acceso a la base de datos, servicios web, sistema de archivos, etc.

OMI este escenario es más adecuado para algo como lo que usarías en WPF. ViewModel View Controller.

Su controlador habla con los servicios comerciales que realizan funciones en objetos de dominio. El controlador convierte los datos devueltos de los servicios comerciales (combinando varios si es necesario) en Modelos de Vista (la "M" en MVC). El modelo de vista se pasa luego a la vista.

Lo mismo a la inversa para tomar las máquinas virtuales de la vista y enviar los datos a los servicios empresariales.

Puede usar S # arp Architecture para estructurar su aplicación correctamente utilizando las mejores prácticas. Hay una aplicación de muestra completa disponible en: Who Can Help Me?

Tal vez este link lo ayude a comprender mejor el Modelo. Pueden desempeñar el papel de Objeto de transferencia de datos o profundizar más en la descripción del enlace. Sin embargo, no deberían ser su DAL en mi opinión. Muchos ejemplos que veo manejan la lógica empresarial y DAL con los patrones de servicio y repositorio.

Consulte el Proyecto MVC Contrib y la muestra del campamento de código para obtener un ejemplo de esto.

También encontré el eCommerce Storefront de Rob Conery y el kit de inicio Northwind MVC para ayudar.

Tiendo a poner mi lógica comercial en los servicios, y los llamo desde el controlador, que reúne los datos y los envía al servicio adecuado.

Para tener una aplicación MVC encima de esto, usaría un patrón de fachada o algo similar, para llamadas proxy a su lógica comercial existente. Entonces, sus servicios son esencialmente fachadas que solo pasan datos a la lógica comercial existente.

De esta forma, hay una ruptura limpia entre la lógica comercial existente y su nuevo código basado en MVC.

[ M ] odel [ V ] iew [ C ] ontroller parece que se dirige a sus 3 niveles, pero ese no es el caso. Realmente organiza cómo se arma su UI. El controlador está en el centro, y típicamente (A) hace cosas que usan objetos de uso [ B ] y (B) desde objetos de uso [ B ] hace que los objetos del [ M ] odel pasen a la [ V ] iew. La parte MVC de su sistema (la funcionalidad UI) no tiene idea de lo que sucede al otro lado de la capa empresarial. DB? ¿Llamadas de servicio? Disco IO? ¿Disparando rayos láser? Entonces, ¿ MVC-B-? sería un acrónimo que describe MVC y cómo se conecta.

Piensa en el [ C ] ontroller en el centro, con una línea que baja a los objetos de [ B ] usiness. El controlador típicamente obtendrá el [ M ] odel de los objetos de [ B ] usiness para pasar a la [ V ] iew, pero el [ M ] odel es solo información. Esa es la clave. El controlador [ C ] es ahora la parte más inteligente del sistema en cierto sentido, pero los objetos de uso [ B ] siguen siendo los más poderosos.

Por lo tanto, los objetos [ M ] odel son una gran parte de la comunicación entre el [ C ] ontroller y los objetos de [ B ] usiness. Además, cada vista tiene un objeto VM ([ V ] iew [ M ] odel) que lleva, que podría ser un [ M ] odel, pero podría ser algo construido por el [ C ] ontroller para pasar conjuntos de información más complicados a la [ V ] iew.

Entonces, un controlador ( 1 ) toma datos del cliente y hace cosas con los objetos comerciales (si es necesario), comunicándose usando el objeto modelo quizás, y luego ( 2 ) obtiene el objeto (s) del objeto [ M ] desde un [ B ] uso objeto (s), construye una máquina virtual y lo da a una vista (varios posibles) para representar.

Al principio, parecerá capas y niveles en todas partes, especialmente desde que ingresar a MVC es un buen momento para aumentar el uso de las interfaces (ver los últimos 3 o 4 principios sólidos ) y las pruebas de unidades . Probablemente tendrá muchos más archivos en su proyecto de los que tendría de lo contrario. Muy rápidamente, como ves, es una gran manera de organizar las cosas.

Como esta parte "superior" del sistema, la parte MVC, simplemente no nos importa cómo se construyeron los objetos [ M ] odel o qué hacen los objetos de uso [ B ] con ellos. ¡No se sorprenda, por supuesto, si su objeto de modelo de cliente se parece mucho a su tabla de clientes de db! Esto es normal y común. Sin embargo, su objeto de cliente [ M ] odel objeto y su cliente [ B ] usiness realmente tendrán vidas separadas. Es un buen momento para considerar el patrón de repositorio .

Lucha contra la tentación de ser flojo y poner mucha lógica en el [ C ] ontroller. Esfuércese en todo momento para poner preocupaciones en el lugar donde están abajo. El [on] ontroller es solo para conectar las cosas. Si se necesita una gran cantidad de código para construir una VM adecuada para la vista, está bien, porque este es el trabajo de los controladores. Con demasiada frecuencia, ve lógica comercial o lógica de representación en el controlador. ¡Ponlo donde corresponde!

Traté de equilibrar la comprensión con la brevedad, pero usted hizo una gran pregunta.