POCO vs DTO: ¿Está bien hidratar parcialmente un objeto de dominio?

Question

A menudo es un requisito tener un objeto de dominio mostrado de varias maneras en la interfaz de usuario; listas, resultados de búsqueda, ver y editar páginas, así como en encabezados, pies de página y ventanas emergentes. Normalmente tienes varias " vistas " " del objeto de dominio, cada uno con diferentes campos mostrados.

La mayoría de los consejos parece ser utilizar un DTO para obtener los datos cuando necesite un subconjunto o superconjunto. Hay muchos gastos generales en el mantenimiento de DTO. ¿Es un mal enfoque simplemente llenar las propiedades del objeto de dominio requerido para cada escenario? Por ejemplo, puede usar un perfil para indicar qué propiedades deben incluirse, por ejemplo:

service.GetDomainObjects (int listID, Profile.ListProfile); service.GetDomainObjects (string searchParam, Profile.SearchProfile);

Answer 1

Para mí, a lo que se reduce esto es a dónde quiere que estén los gastos generales, o bien tendrá un conjunto de clases diferentes para representar sus DTO, o tendrá un conjunto de métodos para que cada uno devuelva lo mismo objeto de dominio pero con diferentes campos que están 'hidratados'.

Un par de preguntas que haría para ayudar a tomar la decisión son:

• ¿cuál es la sobrecarga en la hidratación de todo el objeto? ¿Merece la pena la complejidad agregada (de DTO u objetos parcialmente hidratados)?
• ¿Alguien más va a usar tu código? No confunda a las personas con objetos parcialmente hidratados, los DTO podrían ser más claros cuando las personas mantienen su código.

Tengo una ligera preferencia personal por los DTO, ya que creo que el mantenimiento a largo plazo de su sistema será más fácil. Si usted es una banda de un solo hombre, o esta es una aplicación de un solo uso, puedo entender totalmente que no quiero introducir un montón de clases adicionales que saturen su código.