Separación de preocupaciones - DAO, DTO y BO

Question

Tengo un DAO, DTO y BO. El código siguiente es el resultado:

// Instantiate a new user repository. 
UserRepository rep = new UserRepository(); 

// Retrieve user by ID (returns DTO) and convert to business object. 
User user = rep.GetById(32).ToBusiness<User>(); 

// Perform business logic. 
user.ResetPassword(); 
user.OtherBusinessLogic("test"); 
user.FirstName = "Bob"; 

// Convert business object back to a DTO to save to the database. 
rep.Save(user.ToDataTransfer<Data.DTO.User>()); 

así que estoy tratando de separar las preocupaciones, pero quiero para deshacerse de los "convertidos" en este código. Los "convertidos" en realidad están ubicados en la capa de lógica de negocios (la capa DTO no sabe nada de la capa de lógica de negocios) como un objeto de extensión. El DTO en sí mismo, obviamente, solo almacena datos y no tiene lógica comercial alguna. El UserRepository llama al DAO y al final de GetById usa AutoMapper para mapear desde el DAO al DTO. Los "conversos" (ToBusiness y ToDataTransfer) hacen exactamente lo que dicen.

Un colega mío pensó que podría tener que tener un repositorio de negocios, pero pensó que podría ser un poco torpe. ¿Alguna idea?

Answer 1

resolví esto creando una capa de servicio de negocio. De esta forma, puedo acceder a la funcionalidad a través de la capa Business Service, que a su vez utiliza los Repositorios que consultan el DAL y devuelven los DTO. Los DTO cumplen su función al estar ocupados por el DAL y ayudar a transferir los datos a la capa empresarial (convertidos en objetos comerciales).

Así que el diagrama es el siguiente:

DAL -> Repositorio (devuelve DTO) -> Servicio (devuelve BO)

Funciona muy bien y soy capaz de poner la lógica de negocio en la capa de servicio que lo abstrae del Repositorio mismo. Código de muestra:

// UserService uses UserRepository internally + any additional business logic. 
var service = new UserService(); 
var user = service.GetById(32); 

user.ResetPassword(); 
user.OtherBusinessLogic("test"); 
user.FirstName = "Bob"; 

service.Save(user); 

Answer 2

Esta es la primera vez que veo que un DTO se transforma en un BO, normalmente envía un DTO para ser consumido por una clase BO o método. Cuando el BO está listo y quiere guardar modificaciones en el DTO, lo envía al DAL y lo mantiene.

Answer 3

Mi única fuente de confusión aquí es por qué son necesarias las llamadas a ToBusiness<User>() y ToDataTransfer<Data.DTO.User>().

La responsabilidad del repositorio es gestionar la gestión de datos. Debe ocultar los detalles de implementación (así como las conversiones entre Business Objects y Data Objects).

A UserRepository debe devolver un User sin ningún tipo de fundición.

El UserRepository también debería poder persistir User sin fundición.

El código sería mucho más limpio si todo el casting fue manejado en el repositorio y el código leído como:

UserRepository rep = new UserRepository(); 

User user = rep.GetById(32); 

// Do Work Here 

rep.Save(user);