POCOs debe ser derivado de dtos o no mejor?
-
13-09-2019 - |
Pregunta
Al crear una solución de n niveles, no quiero exponer mis objetos de negocio, pero el uso de DTO en lugar de esto. Por otro lado, no quiero definir doblemente objetos y escribir copiar el código todo el tiempo.
Ahora mi idea sería escribir dtos que contienen todos los campos y propiedades necesarias, pero ninguna lógica (único estado).
A continuación, me gustaría obtener mis objetos de negocio de las organizaciones narcotraficantes, extendiéndolas con mi lógica de negocio, trabajando en las propiedades DTO clases base. Estos objetos también serían los objetos persistieron en el ORM utilizado (NHibernate).
Con ese enfoque, en el lado del servidor que podía trabajar sobre los objetos de negocio y pasarlas directamente al cliente (que se derivan, tan abajo-moldeable). No estaría obligado a exponer mi lógica de negocio y de esa manera ahorrar una gran cantidad de código.
¿Usted cree que el enfoque es razonable?
Saludos,
Sebastian
Solución
Es posible que desee considerar lo siguiente:
" ..., porque manteniendo el DTO conscientes de la objetos de dominio le permite volver a utilizar DTO en diferentes contextos. Del mismo modo, no desea que el dominio objetos que saben sobre el DTO porque que puede significar que cambiar el DTO sería necesario cambiar el código en el lógica de dominio , lo que llevaría a una pesadilla de mantenimiento.
La mejor solución es utilizar el el patrón del ensamblador , que crea dtos de objetos de negocio y viceversa. Ensamblador es una instancia especializada de la Mapper patrón también se menciona en Los modelos de Enterprise Application Architecture .... "
patrón y práctica: Transferencia de objetos de datos
Además, no se han utilizado por mí mismo, pero es posible que desee comprobar hacia fuera AutoMapper como bien.
Otros consejos
me suena razonable. En Linq a SQL, objetos de negocio se derivan de la DTO de por el uso de las clases parciales.
"Entonces me derivar mis objetos de negocio de las organizaciones narcotraficantes" tienen en cuenta que DTO puede tener un aspecto diferente de BO que pueden contener propiedades de 2 o 3 BO