Classes partielles .NET et héritage [fermé]

Question

D'accord, nous avons donc ici un utilitaire interne qui génère des classes de modèles métier à partir de nos tables et vues de base de données, similaires à un ORM (mais pas tout à fait comme). En le maintenant, je me suis dit que les données contenues dans les schémas ne changeraient probablement pas beaucoup. La fonctionnalité, cependant, pourrait. Nous voudrons peut-être ajouter des fonctionnalités supplémentaires ultérieurement. Nous voudrons peut-être générer certaines de ces fonctionnalités et les étendre.

Les classes que nous construisons résideront dans une bibliothèque de classes et seront utilisées par d'autres bibliothèques et applications. Pas de grosse surprise là-bas. Mais le problème ici est de savoir comment concevoir les classes générées de manière à perturber le moins de code possible lors de la régénération d’une classe. Si, par exemple, du code a été ajouté à une propriété (qui représente une colonne dans une table de base de données), nous ne voulons pas perdre cela.

Donc, il y a deux approches qui sautent à l'esprit:

Héritage classique , où tout est réalisé en une seule <<>> monolithique & "; la classe et les consommateurs sont libres d’annuler l’implémentation de base. Cela devient de temps en temps délicat et introduit souvent des maux de tête. De plus, si la classe dérivée n’est pas prudente et oublie d’appeler la fonctionnalité de la classe de base, les choses risquent de mal tourner.

Classes partielles . Dans ce schéma, nous séparons l'objet métier en parties distinctes: les propriétés (qui correspondent aux colonnes) et les comportements. Les comportements pourraient même être décomposés davantage en comportements générés et comportements personnalisés. Comme vous pouvez le constater, le problème de cette approche est sa complexité inhérente. De plus, il y a le problème de nommage.

Voici ma question pour vous, personnes: quand vous faites face à un scénario comme celui-ci (le cas échéant), ou si on vous présentait un scénario comme celui-ci, quelles solutions envisageriez-vous et pourquoi?

Answer 1

La raison pour laquelle les classes partielles sont incluses dans .Net est de faciliter l’utilisation des outils de génération de code.

Si vous générez du code, utilisez des classes partielles. C'est vraiment aussi simple que cela. Pourquoi voudriez-vous prendre le risque que le code doive être régénéré plus tard et que vous deviez effectuer une tonne de travail pour le réactualiser avec des personnalisations?

Je ne trouve pas non plus que la complexité des partiels soit très complexe - c'est simplement une classe divisée en plusieurs fichiers. Code généré dans un fichier, code personnalisé dans l'autre.

Answer 2

Je voudrais aller chemin de classes partielle. Tout simplement parce qu’il est plus naturel de diviser un objet en plusieurs parties. Même Linq2Sql utilise des partiels. Combattez avec la complexité avec des modèles et des conventions appropriées. Et il est plus facile d'effectuer une «mise à jour partielle» (si le code généré est bien structuré) sur des classes partielles.

Si vous ne générez pas de code, utilisez l'héritage de classe (vous y seriez forcé car les partiels ne fonctionneraient pas entre différents assemblys).

Answer 3

C’est exactement le problème que les classes partielles doivent résoudre. Je pense que vous les expliquez peut-être un peu trop loin pour des raisons pratiques. Ma réaction instinctive sans connaître les détails les plus fins de votre application serait d’utiliser un fichier de classe partiel pour tout le code généré d’une classe et un second fichier pour tout le code créé à la main. Proposez une convention de nommage pour les classes partielles générées et respectez-la.

Answer 4

Si vous avez un type à sérialiser (au format xml) et que vous souhaitez ajouter des fonctionnalités, vous devez utiliser une classe partielle et non un héritage. Merci /// M

Answer 5

Vous dites:

  

semblable à (mais pas exactement comme) un ORM

Je dresserais quelques chiffres prévisionnels sur les coûts de maintenance de la solution actuelle (ce qui, à mon avis, est significatif), puis choisissais un ORM, rédigeais une solution de preuve de concept et établissais des chiffres comparatifs pour le maintenir. Je ne suis pas sûr du coût de ce package personnalisé en termes de maintenance, de montée en puissance et d’achat de développeur, mais pour ma part, je n’irais nulle part près d’un & "Custom &"; produit tel que celui-ci. Les connaissances ne sont pas transférables, le risque d'erreur est élevé (toujours le cas de la génération de code) et vous êtes lié aux intracies de la base de données sous-jacente.