Introduction
C'est quelque chose que je me suis également demandé. Une question brûlante que j'ai toujours est similaire à la vôtre;
Quelle serait une bonne convention de dénomination?
Comment devrais-je nommer des choses? Devraient-ils aller dans des dossiers ou des projets?
Après avoir cherché, je soupçonne que la réponse est que ça n'a pas vraiment d'importance. Ce qui est important, c'est que votre solution a une architecture sensée et que vous essayiez de suivre les bonnes pratiques telles que SOLIDE.
Mes héros MVC ASP.NET sur ce sujet sont Jeffrey Palermo, Steve Smith et Jimmy Bogard.
Architecture d'oignon
Jeffrey Palerme discute d'une combinaison de vieilles idées mais les rassemble et lui donne le nom visuellement stimulant de Architecture d'oignon (une lecture recommandée). Jeffrey montre une bonne approche du problème de savoir où mettre les choses. Il explique qu'au centre (ou en haut) de votre application, vous avez votre Cœur. Ce calque est l'endroit où vous devez mettre des interfaces telles que IRepository
et IService
.
Presque toutes vos interfaces devraient aller dans le cœur et tout le reste (autres projets) peut tous faire référence au noyau. De cette façon, tout connaît la structure squelettique de l'application sans connaître les détails de la mise en œuvre.
Essayez d'avoir votre référence de couche d'interface utilisateur aussi peu que possible (dans des limites raisonnables). Dans l'une de mes applications, ma couche d'interface utilisateur (MVC) ne fait référence que le noyau. Tout ce dont il a besoin est injecté avec Injection de dépendance.
Steve Smith discute de l'architecture d'oignon et des idées similaires avec des démonstrations dans Solution MVC Meilleures pratiques: une solution au problème de la solution
Ma solution
Dans mes solutions MVC, j'ai une structure typique comme celle-ci:
- Myproject.core
- Myproject.domain
- Myproject.dependencyInjection
- Myproject.infrastructure
- Myproject.web
- Myproject.tests
La Cœur contient mes interfaces. Il est généralement divisé en dossiers comme les services, les modèles, le domaine, les référentiels, etc.
La Domaine La couche fait référence uniquement au noyau et contient mon implémentation. Il fournit une grande partie des classes de béton pour l'abstraction du domaine dans le noyau. Il traite de nombreuses logiques commerciales, de traitement, de gestion des commandes, de classes de gestionnaires, d'implémentations de services concrètes, etc. Je le considère comme une couche assez intérieure et il fait donc référence le moins possible.
La Dépendance injection La couche contient mon package / framework DI choisi et les détails de l'implémentation. Je le considère comme une couche extérieure; Semblable à l'interface utilisateur ou à l'infrastructure et c'est donc OK s'il fait beaucoup référence. Il n'est pas nécessaire que cette couche soit un projet distinct et de nombreuses personnes vous diront de ne pas le faire. C'est bon; Faites ce qui fonctionne pour la complexité de votre projet. J'aime que mon DI soit sa propre chose. La bonne chose à propos de celle-ci est si séparée est que je pourrais remplacer le framework DI par un autre et les choses iraient bien. Aucune couche ne fait référence au projet DI.
La Infrastructure La couche contient des informations sur la journalisation, le courrier électronique et l'accès aux données. Il contiendra mon Orm de choix. Ce ne sont pas des trucs commerciaux et ce ne sont pas des trucs d'interface utilisateur. C'est le chemin de fer de ma solution pour faire avancer les choses. Il est sur la couche extérieure, mais il ne fait référence que le noyau.
La la toile La couche est mon projet MVC et ne fait référence au noyau.
Complexité et pensées finales
J'ai trouvé des réponses à des questions similaires ici, mais elles ont tendance à impliquer une architecture plus compliquée que ce que j'ai décrit ici
C'est un bon point. Il est important de garder à l'esprit la complexité de votre problème. Mais ne soyez pas dissuadé par de bonnes pratiques de solution. Ma solution et mon architecture à l'oignon ne sont pas nécessairement très complexes et ne font pas vraiment gonfler votre solution. Ils gardent les choses séparées.
Dans Structure du projet évolutif, Jimmy Bogard parle des choses sur-complexes. Si ce que j'ai dit semble trop complexe, suivez les conseils de Jimmy et mettez tout cela dans le seul projet (votre couche d'interface utilisateur). C'est OK - tant que cela vous convient.
N'oubliez pas de prendre ma solution uniquement comme une idée - quelque chose à considérer; Mon approche est une tentative de suivre les conseils de Sage des meilleurs, mais je suis sûr que je n'ai réussi que beaucoup; Je peux (et doit) encore s'améliorer.