Contrôleur: doit-il traiter directement avec la couche de service ou le référentiel?

Question

Il y a tellement d'articles contradictoires en ligne. Quelle est votre opinion personnelle sur ce (pour une application d'entreprise) .....

Dans mon application C#/MVC J'ai installé mon architecture comme suggéré ici, moins l'injection de dépendance et automapper: https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/

En général , en parlant du contrôleur MVC, devrait-il traiter directement avec la couche de service? Ou est-ce toujours une bonne pratique de traiter le dépôt directement? Qu'est-ce qui vous aiderait à décider?

De même, la classe UnitOfWork doit-elle être créée au niveau des contrôleurs puis transférée dans Service/repo?

Merci

Answer 1

Eh bien, Unité de travail, je pense est inutile que DBContext pourrait être l'unité de travail, vous pouvez également utiliser le DbContext comme référentiel. Ai-je besoin de couches de stockage et de service, je pense que l'un d'entre eux suffit, cela dépend de la complexité du projet, le service est en couche lorsque vous avez un projet plus complexe. Vous devriez penser à la façon dont vous pouvez réutiliser votre code, et garder les choses simples, mais ne pas créer beaucoup de couches, avec du code non réutilisable

Answer 2

Personnellement, je pense que la couche de service est de la plus haute importance pour tout API de taille moyenne à grande, et que c'est à ce niveau que vous devez traiter l'unité de travail (si vous décidez d'en utiliser un). La raison pour laquelle vous ne devez pas gérer le référentiel au niveau du contrôleur est de faire preuve de flexibilité dans votre architecture et d'empêcher le couplage étroit de votre service à votre protocole ou à votre implémentation. Par exemple, supposons aujourd'hui que vous exposiez votre service en tant que service REST. Demain, vous voudrez peut-être utiliser un autre protocole (peut-être SOAP ou autre chose). En utilisant la couche de service, la couche de protocole (contrôleurs) devient jetable et peut facilement être remplacée. Un autre exemple, qui encourage la couche de service avec l'injection de dépendance, serait que si à un moment donné, vous vouliez modifier l'implémentation de votre service, vous deviez changer de code à partir du contrôleur au lieu de simplement créer et injecter votre nouvelle implémentation. Cependant, à la fin de la journée, les opinions ci-dessus ne sont que des opinions et des scénarios possibles qui pourraient ou ne pourraient pas s'appliquer à votre projet. Le choix que vous faites devrait dépendre de la nature de votre projet spécifique (taille, complexité, probabilité de changement, ...).

Answer 3

En général, les référentiels contiennent un minimum de code possible. Je veux dire qu'ils ne contiennent que du code pour l'insertion, la mise à jour et la suppression d'éléments de l'implémentation interne. Ils existent parce que vous voulez changer l'implémentation de DAL. Si vous souhaitez utiliser des référentiels directement dans le contrôleur, vous devez écrire des logiques de domaine dans le contrôleur et ce n'est pas une bonne pratique. Les contrôleurs doivent être petits et transmettre uniquement les demandes à la logique ou aux services de domaine.

Donc, dans mon idée, il est préférable d'utiliser les services dans le contrôleur.

Si vous instanciez des UOW dans vos services, vous vous retrouverez avec une nouvelle unité de travail dans chaque service. La création d'une unité de travail peut être coûteuse. Donc, si vous avez besoin de deux ou trois services dans un contrôleur, vous aurez deux, trois unités de travail dans un contrôleur.

Donc encore une fois dans mon idée, il est préférable d'injecter l'unité de travail aux services.Je répète que Repository et Unit of work sont utiles si vous voulez changer les implémentations DAL (par exemple, tester du code avec des données en mémoire).

Answer 4

Eh bien, cela dépend vraiment de votre application. Permettez-moi de vous donner un exemple d'architecture que j'utiliserais.

1. MVC projet de site
2. projet couche d'affaires
3. couche Persisten projet
4. projet de couche commune
5. Tests
projettent

1 Contrôleurs, Vues, ​​ViewModels. C'est ici que vous transférez vos modèles BL dans ViewModels.

2 Votre couche de gestion. Ceci peut être omis si votre BL est sur la base de données et vous êtes seulement intéressé par l'affichage des données. Cependant, si vous démarrez un nouveau projet, c'est ici que BL devrait être. Toutes vos décisions d'affaires, validations et ainsi de suite. De plus, si votre modèle BL ne correspond pas à votre base de données, vous pouvez transformer vos données de base de données en modèles BL

3 Cette couche est uniquement destinée à la base de données. Avec une logique minimale.

4 Objet commun. Comme les méthodes d'extension. Ou d'autres objets utilisés par l'application. Cela devrait être aussi léger que possible!

5 C'est là que vous écrivez des tests pour votre application - ce peut être divisé en plusieurs projets si vous préférez avoir un projet pour chaque couche

Remarques:

1 - Vous devriez aussi penser à votre vue et comment allez-vous séparer les préoccupations entre Controller, ViewModel et votre HTML, javascript etc ... Cela dépend vraiment de la complexité de vos points de vue.

Je vous recommande d'utiliser l'injection de dépendances, il est un excellent outil surtout si vous développez des applications d'entreprise.