Cómo usar los DTO entre UI, BLL, DAL

Question

Estoy tratando de escribir una aplicación pequeña con límites muy estrictos entre BLL y DAL y ahora me pregunto cuál sería la mejor manera de pasar los datos (objetos de transferencia de dominio) entre las capas.

Implementé algunas clases en un nivel de dominio (biblioteca de clases) a las que acceden tanto BLL como DAL. Estas clases básicamente solo contienen propiedades/miembros de datos y actualmente reflejan los datos DAL. Ej:

class CustomerData 
{ 
    // some data fields 
} 

Entonces implementado algunas clases en BLL como:

class Customer : CustomerData 
{ 
    // Some methods 
} 

En mi DAL consigo los registros de clientes de la base de datos mediante LINQ to SQL. Luego asigno el objeto LINQ a mi objeto Dominio por:

CustomerData.field = LinqObject.field 
// Etc 

Mi pensamiento es, pues, que ahora es un ejemplo CustomerData de mi DAL a BLL cuando se le solicite (y que debería pasar una instancia del cliente a la interfaz de usuario).

En mi BLL, recibiré una instancia de CustomerData, pero ahora quiero convertirlo en un Cliente.

Preguntas:

1. ¿Tengo que en mi BLL ahora crear una instancia de cliente y otra vez copiar todos los miembros de campo?
   Cliente c = nuevo Cliente; c.field = CustomerData.field;
2. ¿Cómo puedo crear un cliente de CustomerData sin los pasos de copia del campo?
3. ¿Debería usar composición?
   clase Cliente { CustomerData Data; }
4. ¿Existe alguna forma más efectiva (menos codificación, etc.) para hacer esto en mi diseño actual?
5. ¿Hay mejores formas de hacerlo?
6. ¿Algún comentario en general?

¡Gracias!

Answer 1

generalmente considero que las DTO no son específicas de la capa, creadas/consumidas por DAL, procesadas por BLL y consumidas/creadas por UI.

Normalmente, cada capa es un proyecto separado en la carpeta de la solución VS, por lo tanto, los DTO son otro proyecto al que hace referencia cada capa.

de esta manera si hay un campo que debe existir en la interfaz de usuario, pero no en las otras capas, se puede heredar el DTO.

Answer 2

no está utilizando completamente DTO. En su clase Customer, devuelva CustomerData directamente a su UI.

y no hay necesidad de heredar Customer de CustomerData

EDIT: he utilizado la palabra plenamente aquí porque CustomerData es DTO, así que en vez de devolver al cliente, CustomerData de regreso si lo es su DTO como se ve en la siguiente diagrama.

Una sugerencia, debe usar Repository Pattern para aislar su BLL y DAL.

1]

Answer 3

Algunas notas desde mi punto de vista viene aquí, no soy un oráculo, pero es de esperar que le dará un poco de ayuda :)

para mí es algo que usted tiene demasiados " modelos "aquí. Podría causar confusión y conducir a una gran cantidad de código solo para copiar datos entre diferentes representaciones. Y mucho código significa más errores. Entonces, creo que la herencia entre tus clases de datos y clase de negocios te limita cuando defines tus clases de negocios. ¿Qué tal si quieres crear una clase de negocios que esté compuesta por varias clases de datos? Deberías usar interfaces o composición, creo.

Normalmente, trabajo con un solo modelo conceptual que refleja el dominio comercial. Este modelo se usa tanto en los datos como en la capa empresarial y, en algunos casos, incluso en la capa de presentación (en aplicaciones más pequeñas), como señala Dead Rabit. Para persistencia uso un O/RM como EF 4.

Para proyectos más grandes, especialmente en escenarios distribuidos, utilizo DTO personalizados para la (s) capa (s) UI. Estas clases reflejan las necesidades de la IU, y podrían diferir mucho de las entidades en el modelo conceptual.

Personalmente, creo que Entity Framework 4 te ayuda mucho al crear aplicaciones de acuerdo con esta estructura, si estás en una etapa inicial de tu proyecto y usa .NET 4, ¿te gustaría echarle un vistazo?

1. Sí, probablemente necesite hacerlo.
2. Uso composición
3. Sí, me gustaría utilizar la composición
4. uso, por ejemplo, Entity Framework 4
5. (- "-)
6. ver arriba

Answer 4

Si usted insiste en tener varias capas de DTOs, puede usar AutoMapper para ayudarlo a convertir de uno a otro en una línea de código (usando la misma convención en sus DTO).

CustomerData customerData = Mapper.Map<LinqObject, CustomerData>(linqObjectInstance); 

También debe observar el patrón PresentationModel: http://martinfowler.com/eaaDev/PresentationModel.html

También puede google para MVVM (Model-View-ViewModel) si quiere ir por este camino.