ASP.NET MVC avec couche de service et couche de référentiel, où les interfaces doivent-elles être définies?

Question

Je suis en train de déterminer une architecture en couches assez simple pour une application .NET MVC qui a une couche de référentiel et une couche de service. J'ai trouvé des exemples assez clairs et simples, notamment www.asp.net, et quelques questions et réponses ici, mais je recherche quelque chose qui est un peu plus simple, adapté aux petites applications, mais qui utilise différents projets, pour faire passer l'idée. L'exemple auquel j'ai lié ci-dessus a le référentiel et le service en tant que classes dans l'espace de noms de modèles. Ce n'est tout simplement pas une séparation claire pour que je puisse l'illustrer correctement.

J'ai un projet distinct pour le référentiel qui implémente l'interface iRipository. Il existe un projet séparaté pour le service qui implémente Iservice et prend un iRipository (injection de constructeur). Le service implémente Iservice. Il suffit de cet exemple que le contrôleur instancie le service, pas encore besoin d'un conteneur IOC. Considérez-le comme une étape intermédiaire pour comprendre les meilleures pratiques architecturales, une partie d'une séquence qui construit progressivement pour inclure l'injection de dépendance et éventuellement plus de couches.

La question est: où dois-je définir l'iRespository et Iservice? Les projets de service et de référentiel doivent bien sûr les référencer. Il semble donc clair qu'ils doivent être définis dans un autre projet référencé par les projets de service et de référentiel. Si oui, quelle serait une bonne convention de dénomination? Quelque chose comme xxxxContracts?

De même, pour les modèles de données passés entre les couches de présentation, de service et de référentiel, est-il acceptable d'avoir un projet distinct appelé xxxxmodels référencé par toutes les couches? Je comprends que dans certains cas, les modèles passés entre le service et la couche de référentiel peuvent différer de ceux passés entre la couche de service et la couche de présentation, mais le principe est le même.

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. Je cherche à obtenir une illustration très simple et propre des deux couches qui peuvent être considérées comme une ou deux au-dessus de référencer la couche de données et d'avoir une logique métier dans les contrôleurs, c'est tout. Je sais qu'il y a un argument fort et valable pour aller directement aux meilleures pratiques à part entière, mais tout le monde n'est pas adapté pour faire ce saut en un seul coup.

Answer 1

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.