C# Data Layer y Dto's

Question

Recientemente me he unido a una empresa que usa conjuntos de datos tipeados como su 'Dto'. Creo que son realmente basura y quieren cambiarlo a algo un poco más moderno y fácil de usar. Entonces, estoy tratando de actualizar el código para que la capa de datos sea más genérica, es decir, usando interfaces, etc., el otro tipo no sabe qué es un Dto y estamos teniendo un ligero desacuerdo sobre cómo se debe hacer.

Sin tratar de influir en mi forma de pensar, me gustaría obtener respuestas imparciales de ustedes sobre en qué capas puede estar presente el Dto. Todas las capas; DAL, BL y Presentation o un pequeño subconjunto dentro de estas capas solamente.

Además, si los objetos IList deberían o no estar presentes en el DAL.

Gracias.

Answer 1

Realmente depende de su arquitectura.

Para la mayoría de los puntos debe intentar codificar a las interfaces, entonces realmente no importa cuál es su implementación. Si devuelve ISomething, podría ser su SomethingEntity o su SomethingDTO pero a su código de consumo no le importa menos, siempre y cuando implemente la interfaz.

Debe devolver un IList/ICollection/IEnumerable sobre una colección concreta o matriz.

• Properties should not return arrays
• Do not expose generic lists

Lo que usted debe tratar de hacer primero es separar el código y que sea imprecisa mediante la inserción de algunas interfaces entre sus capas, tales como depósito de la capa de DataAccess. Su repositorio luego devuelve sus entidades encapsuladas por una interfaz. Esto hará que tu código sea más comprobable y te permitirá burlarte más fácilmente. Una vez que tenga las pruebas en su lugar, puede comenzar a cambiar las implementaciones con menos riesgo.

Si empiezas a usar interfaces, sugiero integrar un IoC como Windsor más pronto que tarde. Si lo haces desde el principio, facilitará las cosas más adelante.

Answer 2

Una cosa es que los DataSets son pobres para lograr la interoperabilidad. Incluso los conjuntos de datos tipados tampoco son tan compatibles cuando se trata de consumir conjuntos de datos tipeados de un cliente que no es .net. Consulte this link. Si tiene que lograr la interoperabilidad, entonces luche duro por los DTO; de lo contrario, intente que su equipo comprenda a los DTO durante un período de tiempo dado que los conjuntos de datos no son tan malos después de todo.

En parte de las interfaces, sí debe estar exponiendo las interfaces. Por ejemplo, si devuelve List<T> de DAL, en su lugar debe devolver IList<T>. Algunas personas llegan al extremo de devolver solo IEnumerable<T> porque todo lo que necesita es capacidad de enumerar. Pero luego al hacerlo no se convierta en astronaut architect.

En mis aplicaciones que se han dado cuenta de que en lugar de regresar IList<T>List<T> contamina mi base de código con los códigos de esta manera:

//consider personCollection as IList<Person> 
(personCollection as List<Person>).ForEach(//Do Something) 

Así que yo personalmente tratar de mantener un equilibrio entre la interfaz de regresar o un objeto concreto. Si me preguntas qué estoy haciendo ahora, entonces te diré que estoy volviendo List<T>. Estoy influenciado para no convertirme en astronaut architect.

Answer 3

Siempre uso DTO, nunca DataTable. Pero solo los uso para transferir de BL a DL y al revés. Mis capas de presentación a menudo solo conocen las capas de negocios y servicios en caso de servicio orientado.

Los beneficios puedo ver a utilizar dtos en lugar de tablas de datos:

• refactorización fácil
• fácil producción diagrama
• código más limpio más fácil de leer, sobre todo en la unidad del DAL prueba

Answer 4

Por definición, un DTO es un objeto de transferencia de datos, utilizado para (esperar) transferir datos de una capa a otra.

Los DTO se pueden usar en todas las capas y los he usado bien con servicios web.