Je travaille actuellement en tant que développeur solo sur mon projet actuel. J'ai hérité du projet d'un autre développeur, qui a depuis quitté l'entreprise. Il s'agit d'une application Web de style modèle-vue-contrôleur en C #. Il utilise Entity Framework pour le mappage relationnel des objets. Et il existe deux ensembles de classes différents pour les types dans le modèle de domaine. Un ensemble est utilisé pour interagir avec l'ORM et l'autre est utilisé comme modèle dans le système MVC. Par exemple, il peut y avoir deux classes comme suit:
public class Order{
int ID{get;set;}
String Customer{get;set;}
DateTime DeliveryDate{get;set;}
String Description{get;set;}
}
et
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
}
}
Je peux penser à plusieurs inconvénients de cette approche (plus d'endroits pour changer le code si quelque chose change, plus d'objets assis dans la mémoire, plus de temps passé à copier des données), mais je ne suis pas vraiment sûr des avantages. Plus de flexibilité pour les classes modèles, je suppose? Mais je pourrais obtenir cela en sous-classant également les classes d'entités. Mon inclination serait de fusionner ces deux groupes de classes, ou peut-être que les classes modèles soient des sous-classes des classes d'entités. Alors est-ce que je manque quelque chose d'important ici? Est-ce un modèle de conception commun dont je ne suis pas au courant? Y a-t-il de bonnes raisons de ne pas passer par le refactoriste que je songe?
MISE À JOUR
Certaines des réponses ici me font réaliser que ma description initiale du projet manquait de détails importants. Il existe également un troisième groupe de classes dans le projet: les classes de modèle de page. Ce sont eux qui sont réellement utilisés comme modèle de support de la page. Ils contiennent également des informations spécifiques à l'interface utilisateur et ne seraient pas stockées avec une commande dans la base de données. Un exemple de classe de modèle de page peut être:
public class EditOrderPagelModel
{
public OrderModel Order{get;set;}
public DateTime EarliestDeliveryDate{get;set;}
public DateTime LatestAllowedDeliveryDate{get;set;}
}
Je vois totalement l'utilité de ce troisième groupe distinct ici, et je n'ai pas l'intention de le fusionner avec autre chose (bien que je puisse le renommer).
Les classes du groupe de modèles sont également actuellement utilisées par l'API de l'application, que je serais également intéressé à entendre si c'est une bonne idée.
Je dois également mentionner que le client représenté ici sous forme de chaîne devait simplifier l'exemple, non pas parce qu'il est en fait représenté de cette façon dans le système. Le système réel a le client comme étant un type distinct dans le modèle de domaine, avec ses propres propriétés