¿Dónde colocar código de manipulación de datos y lógica de negocios en la aplicación ASP.NET MVC?

Question

Después de ver muestras de la aplicación Kona de Rob Conery, veo que está usando dos cosas con IoC-ISession, donde tiene código de capa de datos y Servicios, donde tiene una lógica comercial adicional que necesitamos para manipular datos en el almacén de datos . Por ejemplo, es posible que no solo agreguemos un registro al DB, sino que también cambiemos las propiedades de otro registro, aumentemos algunos conteos, recuperemos algo, etc. Tenemos que poner ese código adicional en alguna parte y él lo coloca en esos servicios.

Por ejemplo, tiene un Servicio al Cliente que manipula a los Clientes. Esto requiere que enviemos la instancia de ISession al CustomerService, para que CustomerService pueda usarla para acceder al almacén de datos.

Ahora otra forma de hacerlo sería poner ese código adicional en la clase del Cliente y enviar el ISession (o IRepository, cualquiera que sea la terminología que usemos) a esa clase. Y no tiene ningún servicio. Por lo general, las clases de Cliente, Pedido, Producto, etc. son clases de Modelo, de modo que resultaría en clases de modelos grandes/pesados.

Mi pregunta es, ¿qué solución es mejor? Hasta ahora no tenía esa necesidad porque tenía la mayor parte del código en los controladores, pero ahora que mi aplicación crece, necesito tomar una decisión al respecto y limpiar los controladores.

Actualmente tengo: - controladores de grasa con la lógica de negocio en él, - repositorios muy atómicas, - modelos y ViewModels muy limpias.

¿Debo ir a: - controladores delgados, - repositorios con más código, - modelos con código de lógica de negocio (en concreto deben contener mis clases del modelo como métodos add(), remove(), por ejemplo Customer.Remove() ??)

o para - controladores delgados, - repositorios atómicas, - modelos todavía limpios, - servicios (para encapsular todo lo que no entra en ninguna de las anteriores).

Answer 1

Recomendaría tener repositorios que contengan operaciones atómicas con las clases de modelo y la capa de servicio que depende de esos repositorios para definir las operaciones comerciales. El concepto de AOP podría usarse para iniciar automáticamente una transacción de SQL al comienzo de cada operación comercial y confirmar al final o deshacer en caso de excepción.

Finalmente, los controladores utilizarán esas clases de servicio y convertirán entre los modelos de dominio y los modelos de vista.