Ressources pour la conception de la structure .dll

Question

Je viens juste de sortir d’une réunion de conception et on m’a posé une question sur la façon dont j’ai eu l’une de mes idées sur la façon de structurer certains projets d'un projet que nous construisons. Pour être honnête, je ne sais pas du tout où se trouve cette "idée". est venu de cela semblait tout à fait comme une connaissance naturelle pour moi. Cependant, il serait utile que je puisse appuyer ces opinions sur une analyse documentée.

Est-ce que quelqu'un connaît des ressources traitant explicitement de différents mécanismes pour structurer des assemblages / modules / sources?

MISE À JOUR:

Eh bien, l'idée n'avait rien de spécial. Nous discutions d’une couche d’abstraction pour certains matériels, donc l’application "app". qui consomme ces services pourrait être (en quelque sorte) indépendante de la plate-forme. Auparavant, nous avions un fichier .dll qui déclarait les interfaces requises par l'application et un fichier d'implémentation .dll qui les implémentait pour la plate-forme existante. Nous avons maintenant deux plates-formes, mais elles sont très similaires. Pour éviter la pollution des interfaces .dll ou un scénario hideux où les implémentations se référencent, nous avons simplement suggéré de créer un autre .dll situé entre les interfaces et les tables platformpl.dll spécifiques où les implémentations abstraites courantes peuvent vivre.

Answer 1

Si vous en avez l'occasion, consultez le livre de Robert C. Martin:

Principes, modèles et pratiques agiles en C # (nouvelle version destinée spécifiquement à .Net)

Un chapitre consacré à la conception des composants répond (probablement) à votre question.

En résumé, et après avoir lu ce livre, je recommande toujours de séparer les composants selon ces critères:

• Les assemblys sont des unités ou peuvent être réutilisés : si des classes doivent être utilisées ensemble, elles vont dans le même assemblage.

• Les assemblys sont des unités de changement : si certaines classes ne doivent pas changer pour la même raison, elles ne devraient probablement pas appartenir au même assemblage.

• Les assemblys sont des unités de déploiement : si certaines classes doivent être déployées physiquement au même endroit, elles devraient probablement figurer dans le même assemblage.

Bien sûr, ce ne sont que des heuristiques et non des recettes. Vous devez éventuellement décider de la quantité de chacune de ces trois heuristiques de conception dont vous avez besoin en fonction des objectifs architecturaux de votre application (en particulier des objectifs architecturaux pour le déploiement et l'évolution / la modification).