Y a-t-il un inconvénient à trop de granularité dans les projets structurants?

Question

J'ai beaucoup de classes dans mon BLL. Supposé que j'ai ItemBLL, ItemType BLL, EmployeeBLL etc., y a-t-il un inconvénient à les placer dans un projet séparé chacun? Certains d'entre eux sont logiquement groupables mais il y a n'importe quel problème en plaçant chaque classe dans un projet séparé (disons que les maintenir n'est pas un problème).

Qu'en est-il des avantages de les regrouper?

Answer 1

La complexité est le plus gros problème. Plus vous avez d'assemblées, plus vous devez suivre. Si une application a besoin de quelque chose, il y a une bonne possibilité qu'elle ait besoin d'avoir une référence aux autres si elles sont connectées à l'intérieur. Cela ne veut pas dire qu'il est mauvais d'avoir plus d'assemblages. Il peut y avoir des avantages à les séparer, comme ceux qui sont chargés en mémoire quand (ils sont chargés à la demande lorsque l'application en a besoin).

Il n'y a pas de règle absolue à laquelle on est meilleur, cela dépend de la situation. Personnellement, à moins que vous n'ayez une raison de les séparer, je les combinerais. Cela facilite le déploiement et l'administration à long terme. En gardant également les classes dans le même assembly (au moins en C# avec le internal modifier), vous pouvez leur donner la possibilité d'accéder aux fonctions internes à l'assembly tout en bloquant les classes de référence externes.