que - dto c# ejemplo

¿Cómo puedo reducir la duplicación de objetos de dominio/entidad/DTO?

Question

Estoy en el proceso de rediseñar mi proyecto actual para que sea más fácil de mantener y hacer lo mejor para seguir las buenas prácticas de diseño. Actualmente tengo una solución con un componente de Silverlight, un host de ASP.Net para dicha aplicación de SL que también contiene un servicio WCF RIA y una biblioteca de clases compartida para que tanto SL como el servicio de WCF puedan compartir objetos. La lógica de negocios está dispersa por todas partes, y todas las operaciones de CRUD están codificadas a mano dentro de mis servicios WCF. Por lo tanto, estoy creando una nueva estructura para todo y llevaré este lío al nuevo formato. En el proceso de hacer esto, me doy cuenta de que estoy duplicando clases cuando no sé si debería hacerlo.

Mi nueva estructura se presenta como tal:

Cliente:
Reporting.Silverlight = Aplicación Silverlight. Esto hará referencia a mis clases de DTO.
Reporting.Web = Mantiene mi aplicación de SL y es el principal punto de entrada para que la gente acceda a ella.

Negocio:
Reporting.Services = Mis servicios WCF viven aquí. Mi aplicación de SL hará llamadas a esto para hacer cosas, y estos servicios devolverán clases DTO.
Reporting.Services.Contracts = Mantiene mis interfaces para los servicios WCF y contiene mis clases DTO con los decoradores DataContract.
Reporting.Domain = Contiene los objetos de mi dominio y la lógica empresarial

Datos:
Reporting.Data.Contract = Conserva mis interfaces para el repositorio y la unidad de trabajo
Reporting.Data = Implementación concreta del repositorio / UoW. El contexto de Entity Framework 5 se define aquí.
Reporting.Data.Models = Contiene todos los objetos de mi entidad para que EF5 pueda hacer su trabajo con SQL.

Tengo 3 lugares donde tengo casi la misma clase, y a mí me huele. Dentro de Reporting.Services.Contracts Tengo un DTO que se entrega al cliente de SL. Aquí hay uno como ejemplo:

[DataContract(Name = "ComputerDTO")]
public class ComputerDTO
{
[DataMember(Name = "Hostname")]
public string Hostname { get; set; }
[DataMember(Name = "ServiceTag")]
public string ServiceTag { get; set; }
// ... lots more
}

Creo que el DTO anterior está bien, ya que es solo un conjunto de propiedades que se pasan al cliente de SL. La gran mayoría de mis propiedades DTO se asignan a las propiedades 1: 1 de los objetos de mi Entidad, excepto los campos de ID. Aquí está mi objeto Entidad que corresponde con el DTO anterior:

[Table("Inventory_Base")]
public class ComputerEntity
{
// primary key
[Key]
public int AssetID { get; set; }
// foreign keys
public int? ClientID { get; set; }
// these props are fine without custom mapping
public string Hostname { get; set; }
public string ServiceTag { get; set; }
// ... plus a bunch more in addition to my navigation properties
}

Estoy utilizando el primer acercamiento de código con EF5. Todavía estoy en las primeras etapas de mi reescritura, y hasta ahora tengo la impresión de que la lógica de negocios NO debería estar dentro de mi Entidad EF. Los DTO tampoco deberían tener lógica de negocios. Eso significa que entra en mi modelo de dominio, ¿verdad? Bueno, eso da mi tercera clase casi idéntica en Reporting.Domain

public class Computer
{
public string Hostname { get; set; }
public string ServiceTag { get; set; }
// ... lots more, pretty much mirrors the DTO
public string Method1(string param1)
{
// lots of methods and logic go in here
}
}

Tener 3 clases casi idénticas no puede ser la manera correcta de hacerlo, ¿verdad? ¿Debería colocar toda mi lógica de negocios dentro de la entidad de EF, y luego proyectar el resultado en un DTO que pase a través del cable? Si es una buena idea meter toda mi lógica de dominio / negocio dentro de las clases de entidad EF, estructuralmente, ¿debería mover ese conjunto a mi capa empresarial y fuera de mi capa de datos, aunque esos objetos son los que se guardan en mi base de datos? Idealmente, estoy tratando de mantener cualquier referencia al Entity Framework contenida en mis proyectos de datos y fuera de mis proyectos empresariales. Tengo alrededor de 200 o más clases que estoy transfiriendo y abarcaré mi dominio, y espero que esto se escale a mucha más funcionalidad una vez que termine esta reescritura. Cualquier información sobre cómo estructurar esta cosa y mantenerla en seco sería muy apreciada.

En caso de que ayude a definir qué es lo que estoy tratando de hacer mejor, avíseme si debo incluir la metodología de repositorio / unidad de trabajo que estoy siguiendo.

Answer 1

Tener 3 clases casi idénticas no puede ser la manera correcta de hacerlo, ¿verdad?

En mi opinión, no son "3 clases casi idénticas", no tienen el mismo propósito. Son más bien múltiples facetas de la misma noción de dominio, cada una adaptada a las necesidades de una capa específica.

Es el precio a pagar por la modularidad y la clara separación de preocupaciones. Cuantos más puertos (como en Puertos y adaptadores de Arquitectura hexagonal ) tenga, más facetas necesitará y más mapeo tendrá que hacer.

Un buen artículo sobre esto: http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/