Comment c'est mauvais? J'ai lu d'innombrables articles et j'ai jamais créé des données de données abstraites avec un comportement avant, mais il semble que cela résoudra ainsi un problème que je dois m'empêcher de créer des usines partout pour déterminer une implémentation de sous-classe. Ma question est que je serai puni si je décide d'ajouter un comportement à mes contrats de données? Bien sûr, ils ne peuvent pas être consommés et sont là pour effectuer certaines opérations spécifiques à ce type de sous-classe avant d'invoquer des appels de référentiel et les données sont persistées. Je peux créer des classes de "manager" pour chaque sous-classe, mais cela me renvoie dans les usines et j'essaie une approche plus polymorphe. Merci d'avance.
4 Réponses :
Pourquoi ne pouvez-vous pas créer votre contrat de données (myDataContract) de manière classique, juste des champs de données, rien d'autre, puis de dériver votre classe de comportement à partir de celui-ci? Ainsi, Vous avez une bonne séparation de préoccupations, votre contrat de données n'est pas «pollué» par comportement, il ne peut pas vraiment traiter de toute façon ..... Marc
Un bon compromis pour mettre le comportement directement dans vos données de données serait de définir des comportements comme Extension Méthodes dans le même assemblage que vos contrats ou une assemblée différente entièrement. Facultativement, les méthodes d'extension peuvent être placées dans un espace de noms distinct des contrats afin d'isoler davantage la séparation des données et du comportement.
De cette façon, vos contrats sont conservés, mais en même temps, les consommateurs .NET de vos contrats auraient un moyen facile d'importer des fonctionnalités supplémentaires relatives à ces données de données.
Vous pouvez ajouter tout le comportement que vous souhaitez sur vos contrats de données. Vous devriez clairement documenter le fait que le comportement ne sera pas visible pour les clients ou que quelqu'un sera déçu plus tard. Documez également le fait que les soins doivent être pris pour ne pas ajouter de données dépendantes de la mise en œuvre au contrat de données, car ce n'est pas tout ce que vous souhaitez passer aux clients.
Dans l'ensemble, je pense que vous feriez mieux de laisser les contrats de données être des contrats de données et de laisser le comportement.
«Je pense que vous feriez mieux de laisser les contrats de données être des contrats de données et de laisser le comportement d'entre eux». AMEN À CELA!
À un moment donné, vous allez utiliser Membewiseclone et implémenter des interfaces sans traduction de données intermédiaires inutiles (et même pire, entretien inutile). Les méthodes d'extension sont destinées au moment où vous n'avez littéralement aucun contrôle sur la définition de l'objet, mais nécessitent toujours une fluidité orientée objet; Ils ajoutent des travaux occupés dans une autre situation et des définitions de classe de dispersion pire que C / C ++. Buck the "Tendances" et faire ce qui fonctionne pour vous, vous pourriez simplement découvrir un modèle qui change tout le nom de balle (comme l'asyncénumérateur d'Asyncenumerator de Jeffrey Richter).