¿Deben las propiedades en Data Transfer Object expandir las claves externas o simplemente exponer sus claves primarias?

Question

Tengo un EmployeeDTO que representa un registro de empleado en la base de datos.La tabla Empleado tiene una relación con un Departamento y una relación de 1 a varios con el Permiso.

En mis entidades, estos se representan como una propiedad de Departamento completamente expandida y una Lista de objetos de permiso completamente expandidos.

La pregunta es ¿debería el DTO tener una propiedad DepartmentDTO completamente expandida de un DepartmentId?¿Debería el DTO tener una lista de propiedades PermissionDTO completamente expandidas de List of PermissionId?

Answer 1

Al igual que todo en el diseño, depende de sus necesidades.

• Si necesita ver y enlazar a las propiedades secundarias y desea para que sea lo más fácil posible para desarrolladores para usar sus DTO, puede quiero métodos explícitos de fábrica para dar expandió completamente las propiedades secundarias.
• Si desea simplificar el código, no expandir las propiedades de la clave externa y solo deja que los desarrolladores obtengan al niño objeto / colecciones que quieren por clave según sea necesario.

Puede tener problemas en la recursividad; ¿También expande todas las propiedades de clave externa del objeto Departamento? ¿Qué pasa si hay una referencia a otro EmployeeDTO en una subclase de Departamento?

Entity Framework de Microsoft, así como otros frameworks de objetos comerciales populares, manejan este concepto mediante la carga diferida: solo obtienen la propiedad secundaria ampliada completa si el código lo solicita. Esta es probablemente la solución más flexible, pero tiene un poco de sobrecarga / retraso ya que las propiedades secundarias no se pueden recuperar en la misma llamada a la base de datos que el objeto principal. Por supuesto, estos no son puramente DTO.

Answer 2

Sí y No. Depende de la llamada y de si necesitaría todas las propiedades adicionales en cada llamada.También puede depender de la tecnología ORM que utilice, que puede implementar la carga diferida y puede afectar su decisión (si está pasando objetos de entidad directa, aunque no se recomienda ).

Es común crear un DTO de caso que contenga todas las propiedades necesarias y uno o más objetos DTO que exponen más funcionalidades y se utilizan en otros métodos.Por ejemplo, tengo una clase BasicUser que solo contiene UserName y DisplayName y tengo User que contiene más incluyendo Permissions y hereda de `BasicUser.