Pierde la capacidad de tener una lógica comercial en el medio.
No estoy de acuerdo con este.
Si la lógica de negocios está donde debería estar: en el modelo de dominio, llamar al repositorio en el controlador (o mejor) usar el encuadernador de modelos para obtener el método agregado de raíz y llamada me parece perfectamente correcto.
Los servicios de aplicación se deben utilizar cuando hay demasiados detalles técnicos involucrados que podrían desordenar los controladores.
que he visto a varias personas mencionan el uso de quelantes modelo para poner en un acuerdo de recompra últimamente. ¿De dónde viene esta loca idea?
Creo que estamos hablando de 2 cosas diferentes aquí. Sospecho que su 'encuadernador modelo' significa usar el modelo simultáneamente como un modelo de vista y vincular los valores cambiados de la IU directamente a la misma (lo cual no es malo en sí mismo y en algunos casos yo iría por ese camino).
Mi 'modelo de aglomerante' es una clase que implementa 'IModelBinder', que toma repositorio en el constructor (que se inyecta y por lo tanto - se puede ampliar si es necesario el almacenamiento en caché con un poco de composición básica) y lo utiliza antes de la acción se llama a recuperar raíz de agregado y reemplazar int id o Guid id o string slug o whatever argumento de acción con el objeto de dominio real. Al combinar eso con el argumento del modelo de vista de entrada, podemos escribir menos código. Algo como esto:
public ActionResult ChangeCustomerAddress
(Customer c, ChangeCustomerAddressInput inp){
c.ChangeCustomerAddress(inp.NewAddress);
return RedirectToAction("Details", new{inp.Id});
}
En mi código real que es un poco más complejo que causa incluye la validación ModelState y algo de manejo de excepciones que podrían ser lanzada desde el interior del modelo de dominio (extraído en el método de extensión del controlador para su reutilización). Pero no mucho más. Hasta el momento, la acción de controlador más larga es ~ 10 líneas de longitud.
Puede ver la implementación de trabajo (bastante complejo y (para mí) complejo innecesario) here.
¿Estás haciendo aplicaciones CRUD con Linq To Sql o estás intentando algo con lógica de dominio real?
Como puede ver (con suerte), este tipo de enfoque en realidad casi nos obliga a avanzar hacia la aplicación task based en lugar de la basada en CRUD.
Al hacer todo acceso a los datos en su capa de servicios y el uso de COI se puede ganar un montón de beneficios de AOP como el almacenamiento en caché invisible, gestión de transacciones, y la composición fácil de componentes que no puedo imaginar que se obtiene con enlazadores de modelos.
... y tener nueva capa de abstracción que nos invita para mezclar con la infraestructura lógica de dominio y pierden el aislamiento del modelo de dominio.
Por favor enlighten me.
No estoy seguro si lo hice. No creo que esté iluminado yo mismo. :)
Here es mi clase de base de encuadernador actual. Here's una de las acciones del controlador de mi proyecto actual. Y here's "falta" de lógica comercial.
En la práctica, no tengo ejemplos de paso como este en mi código. Dicho esto, uno de los propósitos del repositorio es proporcionar la capacidad de simularlo para fines de pruebas unitarias, por lo que la capa adicional de abstracción puede ser útil por esa sola razón. –
@Robert ¿Qué hay de malo en escribir pruebas contra controladores y repositorios simulados? aparte de burlarse de las dependencias de los controladores, ¿qué más tendría cambiar los servicios? –
@Arnis: supongo que lo que quise decir es que el repositorio abstrae la base de datos de tu código de servicio, por lo que si inyectas una dependencia de repositorio diferente, supongo que puedes llamar a eso un "simulacro". –