Quel est l'avantage d'avoir des modèles POCO purs?
Quel est l'avantage majeur d'avoir des modèles POCO purs? J'ai l'impression que les modèles doivent être propres et simples, mais j'ai tendance à aimer maintenir la maintenance des objets enfants dans les classes de modèles. Par exemple, si j'ai un ClassA et ClassB définis comme suit:
public class ClassA
{
public string MyProp { get; set; }
public IEnumerable<ClassB> Children { get; }
public void AddChild(ClassB newChild) { /*... */ }
public void RemoveChild(ClassB child) { /* ... */ }
}
public class ClassB
{
public string SomeProp { get; set; }
}
Y a-t-il quelque chose d'intrinsèquement mauvais avec les méthodes d'ajout et de suppression? Dois-je à la place simplement exposer la liste et autoriser le code client à ajouter tout ce qui passe la responsabilité de validations de données simples comme non nul et non dupliqué dans une autre classe?
Toute aide est la bienvenue, merci.
Vos deux questions ne sont pas liées.
Quel est l'avantage d'avoir des modèles POCO purs?
Un POCO pur ne dépend pas d'un cadre d'entreprise, d'une convention, [] thingy, ou est intimement lié à un objet qui est également dépendant. En d'autres termes, le monde peut complètement changer autour d'un POCO et il continue de faire ce qu'il fait sans se soucier. Vous ne pouvez pas le casser en mettant à jour un cadre, en le déplaçant dans un nouveau système ou en le regardant de façon amusante. Il continue de fonctionner. Les seules dépendances sont les choses qu'il demande explicitement.
POCO n'est rien de plus que l'idée POJO. Le J a été changé en C parce que les gens vous regardent bizarrement quand vous expliquez un concept qui a Java dans son nom si ces gens utilisent C #. L'idée ne dépend pas du langage. Ils pourraient l'ont simplement appelé Plain Old Objects. Mais qui veut se vanter d'utiliser POO?
Je laisse Fowler expliquer les origines:
Le terme a été inventé alors que Rebecca Parsons, Josh MacKenzie et moi nous préparions pour une conférence lors d'une conférence en septembre 2000. Dans la conférence, nous soulignions les nombreux avantages de l'encodage de la logique métier en standard Java objets plutôt que d'utiliser Entity Beans. Nous nous sommes demandé pourquoi les gens étaient si contre l'utilisation d'objets ordinaires dans leurs systèmes et avons conclu que c'était parce que les objets simples n'avaient pas de nom de fantaisie. Nous leur avons donc donné un, et il est très bien pris.
Quant à votre autre question:
Y a-t-il quelque chose d'intrinsèquement mauvais avec les méthodes d'ajout et de suppression?
Je n'aime pas A connaître directement B. Mais c'est une chose DIP pas une chose POJO .
Avec Ajouter et supprimer, vous implémentez Collection<T> Caractéristiques. Demandez-vous pourquoi utilisez-vous IEnumerable<T> au lieu de List<T> ou une autre classe mutable? Apparemment, ce n'est pas parce que votre collection doit être en lecture seule.
La seule raison pour laquelle je peux penser est que vous voulez contrôler les méthodes d'accès que vous souhaitez publier. Dans ce cas, il serait plus agréable de créer votre propre classe de collection, d'encapsuler une liste, d'implémenter vos méthodes de sélection Ajouter et supprimer et d'implémenter IEnumerable<T>. Utilisez ensuite cela au lieu de IEnumerable<T> pour le type de votre collection enfant.
Mais il me semble List<ClassB> vous servirait probablement bien.
À quoi AddChild ajoute-t-il et que RemoveChild supprime-t-il? Si cela provient de la base de données (ou du magasin de persistance de tout type), vous avez en quelque sorte un enregistrement actif. Pas nécessairement toujours une mauvaise chose, mais cela vous rapproche définitivement d'avoir à vous soucier des cadres, des conventions, des dépendances, etc., comme le mentionne @CandiedOrange.
Dans le même temps, quel serait l'intérêt d'éviter une dépendance de ClassA à ClassB (ou au moins InterfaceB) s'ils sont tous dans la même application? Dans le domaine réel que votre application modélise, les choses dépendent les unes des autres. Les objets du monde réel ont des collections d'autres objets qui leur "appartiennent". Il est tout à fait approprié de représenter ces relations dans votre code.
La seule raison pour laquelle cela devient même un peu compliqué est qu'il semble que vous ayez besoin de gérer exactement la façon dont un ClassB devient associé et dissocié de ClassA. Vous avez donc un petit comportement à mettre en œuvre. Vous pouvez l'implémenter dans la classe (qui est totalement "légale"; voir https://stackoverflow.com/a/725365/44586 ), ou vous pouvez avoir une sorte de classe distincte qui contient ce comportement. Faites ce qui convient le mieux à votre situation personnelle.
Dans tous les cas, POJO/POCO est vraiment juste OOP comme il était censé être, sans fioritures et sans encombrement. Suivez les principes OOP et vous serez en sécurité.