Attualmente sto lavorando come sviluppatore solista per il mio progetto attuale. Ho ereditato il progetto da un altro sviluppatore, che da allora ha lasciato la società. È un'applicazione web in stile model-view-controller in C #. Utilizza Entity Framework per la mappatura relazionale di oggetti. E ci sono due diversi gruppi di classi per i tipi nel modello di dominio. Un set viene utilizzato per interagire con l'ORM e l'altro viene utilizzato come modello nel sistema MVC. Ad esempio, potrebbero esserci due classi come segue:
public class Order{
int ID{get;set;}
String Customer{get;set;}
DateTime DeliveryDate{get;set;}
String Description{get;set;}
}
e
public class OrderModel{
String Customer{get;set;}
DateTime DeliveryDate{get;set;}
String Description{get;set;}
public OrderModel( Order from){
this.Customer= from.Customer;
// copy all the properties over individually
}
public Order ToOrder(){
Order result =new Order();
result.Customer = this.Customer;
// copy all the properties over individually
}
}
Riesco a pensare a diversi inconvenienti a questo approccio (più posti per cambiare codice se qualcosa cambia, più oggetti in memoria, più tempo impiegato per copiare dati in giro), ma non sono sicuro di quali siano i vantaggi qui. Più flessibilità per le classi modello, suppongo? Ma potrei ottenere questo anche sottoclassi delle classi di entità. La mia inclinazione sarebbe quella di unire questi due gruppi di classi, o possibilmente fare in modo che le classi modello siano sottoclassi delle classi di entità. Quindi mi manca qualcosa di importante qui? Si tratta di uno schema di progettazione comune di cui non sono a conoscenza? Ci sono buone ragioni per non passare con il refactor che sto contemplando?
Aggiorna
Alcune delle risposte qui mi stanno facendo capire che la mia descrizione iniziale del progetto mancava di alcuni dettagli importanti. Esiste anche un terzo gruppo di classi esistenti nel progetto: le classi del modello di pagina. Sono quelli che vengono effettivamente utilizzati come modello che supporta la pagina. Contengono inoltre informazioni specifiche per l'interfaccia utente e non vengono archiviate con un ordine nel database. Una classe del modello di pagina di esempio potrebbe essere:
public class EditOrderPagelModel
{
public OrderModel Order{get;set;}
public DateTime EarliestDeliveryDate{get;set;}
public DateTime LatestAllowedDeliveryDate{get;set;}
}
Vedo totalmente l'utilità di questo terzo gruppo che è distinto qui, e non ho intenzione di fonderlo con qualcos'altro (anche se potrei rinominarlo).
Le classi nel gruppo di modelli sono attualmente utilizzate anche dall'API dell'applicazione, che sarei anche interessato a sentire se fosse una buona idea.
Vorrei anche menzionare che il cliente rappresentato come una stringa qui era per semplificare l'esempio, non perché è effettivamente rappresentato in quel modo nel sistema. Il sistema attuale ha il cliente come un tipo distinto nel modello di dominio, con le sue proprietà