Come ridurre la duplicazione di oggetti dominio/entità/DTO?

Question

Io sono nel processo di riprogettazione mio progetto in corso di essere più gestibile, e fare del mio meglio per seguire le buone pratiche di progettazione. Attualmente dispongo di una soluzione con un componente Silverlight, host ASP.Net per la suddetta app SL che contiene anche un servizio RIA WCF e una libreria di classi condivise in modo che sia SL sia il servizio WCF possano condividere oggetti. La logica aziendale è sparsa ovunque e tutte le operazioni CRUD sono codificate a mano all'interno dei servizi WCF. Quindi, sto creando una nuova struttura per tutto e porterò questo casino nel nuovo formato. Nel processo di fare questo, trovo che sto duplicando le classi quando non so se dovrei essere.

La mia nuova struttura si articola in quanto tale:

Cliente:
Reporting.Silverlight = applicazione Silverlight. Questo farà riferimento alle mie classi DTO.
Reporting.Web = Dichiara il mio SL app ed è il punto di ingresso principale per le persone per arrivare ad essa.

Affari:
Reporting.Services = I miei servizi WCF vivono qui. La mia app SL invierà chiamate a questo scopo e questi servizi restituiranno le classi DTO.
Reporting.Services.Contracts = mi tiene le interfacce per i servizi WCF, e contiene le mie classi DTO con i decoratori DataContract.
Reporting.Domain = Contiene i miei oggetti di dominio e la logica di business

dati:
Reporting.Data.Contract = mi tiene le interfacce per il repository & unità di lavoro
Reporting.Data = Implementazione concreta del repository/UoW. Il contesto Entity Framework 5 è qui definito.
Reporting.Data.Models = contiene oggetti tutta la mia entità così EF5 può fare la sua cosa con SQL.

Ho 3 posti in cui ho quasi la stessa classe esatto, e per me puzza. All'interno di Reporting.Services.Contracts Ho un DTO che viene consegnato al client SL. Qui è uno come esempio:

[DataContract(Name = "ComputerDTO")] 
public class ComputerDTO 
{ 
    [DataMember(Name = "Hostname")] 
    public string Hostname { get; set; } 

    [DataMember(Name = "ServiceTag")] 
    public string ServiceTag { get; set; } 

    // ... lots more 
} 

penso che quanto sopra DTO va bene, in quanto solo un mucchio di proprietà che viene passato al client SL. La stragrande maggioranza delle mie proprietà DTO mappano alle proprietà 1: 1 dei miei oggetti Entity ad eccezione dei campi ID. Ecco il mio oggetto entità che corrisponde con il DTO sopra:

[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 
} 

Sto usando il primo approccio con il codice di EF5. Sono ancora nelle fasi iniziali della mia riscrittura, e finora ho l'impressione che la logica aziendale NON dovrebbe essere all'interno della mia Entità EF. Anche le DTO non dovrebbero avere una logica aziendale. Ciò significa che entra nel mio modello di dominio, giusto? Bene, questo dà la mia terza classe quasi identica nel Reporting .Dominio

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 
    } 
} 

avere 3 classi quasi identici non possono eventualmente essere il modo giusto per andare su questo, no? Dovrei mettere tutta la mia logica aziendale all'interno dell'entità EF, quindi proiettare il risultato in un DTO che viene passato attraverso il filo? Se è una buona idea racchiudere tutta la mia logica dominio/business all'interno delle classi di entità EF, strutturalmente dovrei spostare quell'assembly sul mio livello aziendale e fuori dal mio livello dati, anche se quegli oggetti sono quelli che vengono salvati nel mio database? Idealmente sto cercando di mantenere qualsiasi riferimento a Entity Framework contenuto all'interno dei miei progetti di dati e al di fuori dei miei progetti di business. Ho circa 200 classi circa che sto facendo il porting e comprenderò il mio dominio, e mi aspetto che questa cosa si riduca a molte più funzionalità una volta che ho fatto questa riscrittura. Qualsiasi idea su come strutturare questa cosa e tenerla ASCIUTTA sarebbe molto apprezzata.

Nel caso in cui aiuti a definire ciò che sto cercando di fare meglio, fammi sapere se dovrei includere la mia metodologia repository/unitofwork che sto seguendo.

Answer 1

Avere 3 classi quasi identiche non può essere il modo giusto per andare su questo, vero?

IMO non sono "3 classi quasi identiche", non hanno lo stesso scopo. Sono piuttosto sfaccettature della stessa nozione di dominio, ognuna personalizzata per le esigenze di un livello specifico.

È il prezzo da pagare per la modularità e la chiara separazione delle preoccupazioni. Maggiore è il numero di porte (come nelle schede & Porte), più sono le sfaccettature necessarie e maggiore è la mappatura da eseguire.

Un buon articolo su questo: http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/