0
votes

Où mettre Data Logic dans MVC?

Lors de la configuration d'un projet MVC, j'aime avoir des projets séparés dans ma solution Visual Studio. Un projet gère les choses principales, comme les contrôleurs et les vues, puis j'ai un projet séparé pour la couche de données et un projet pour les utilitaires. Le projet principal fait référence aux deux autres projets. La couche de données fait référence au projet Utilities.

Avec cette structure, je suis confronté à un problème, lorsque j'essaie d'implémenter une méthode utilitaire comme celle-ci:

public static string GetCountryFromID(int id)
{  
   dev_Entities dbContext = new dev_Entities();
   var country = from c in dbContext.countries
                 where c.id == id
                 select c;

   return country.FirstOrDefault().country_name.Trim(); 
}

La méthode fonctionne avec la base de données, mais mon projet Utilities ne peut pas référencer le projet Data Layer, car sinon, il y aurait une dépendance circulaire, ce qui est interdit par Visual Studio. Alors, quelle est la meilleure façon de travailler sur la base de données et où dois-je mettre les méthodes utilitaires appartenant?

Edit: J'ai choisi cet exemple pour une méthode utilitaire, car c'est une action que je dois faire souvent et je voudrais éviter le code en double.

c# entity-framework asp.net-mvc

4 commentaires

C'est peut-être évident, mais quelle partie de ce code fait référence à votre projet Utilities?

Pourquoi appelez-vous cela une «méthode utilitaire»? Il accède très clairement à votre base de données.

Si votre couche de données a une structure rigide et que vous avez besoin d'un élément plus flexible qui accède au même contexte, vous pouvez créer une classe partielle. Vraiment pas une couche séparée, mais logiquement.

Ne référencez le DbContext qu'à l'intérieur de votre projet de couche de données - nulle part ailleurs. Je suppose que votre échantillon provient de votre projet Utilities.

3 Réponses :

1
votes

En ce qui concerne la structure du projet, il est important d'avoir une séparation au moyen de différents projets, par exemple la logique métier, l'accès aux données, les utilitaires, etc.

Cela aide à séparer les préoccupations. Mais ce n'est qu'un premier pas vers la séparation des préoccupations. Pour le renforcer davantage, l'utilisation d'interfaces est encouragée afin qu'une implémentation puisse être facilement échangée avec un autre type d'implémentation.

En ce qui concerne la question de la dépendance circulaire, la méthode mise en place dans Utility n'est pas exactement une méthode utilitaire, c'est plutôt une méthode d'accès aux données. Je pense que l'accès à DBcontext doit être effectué de manière contrôlée à partir du projet de couche de données uniquement.

0 commentaires

1
votes

Première question: est-ce une structure recommandée?
Oui.
Deuxième question: avec cette structure, je suis confronté à un problème ...
D'après votre exemple de code limité, je ne vois pas où se situe le conflit. Mais votre projet d'accès aux données doit avoir un travail et un seul travail: parler à la base de données.
Votre projet d'accès aux données NE DEVRAIT PAS BESOIN de savoir quoi que ce soit sur votre projet Utilities. Il ne doit y avoir rien dans le projet Utilitaires qui soit nécessaire au projet d'accès aux données pour communiquer avec la base de données.
En outre, vous ne devez pas non plus appeler le projet d'accès aux données à partir du projet Utilitaires. Les deux ne devraient vraiment pas savoir que l'autre existe.
Une structure commune devrait ressembler à ceci, dans une application Web simple:
                  [UI]
                   |
             [Business Logic]
               |         |
           [Utility]  [DataAccess]
Où chacun | représente une référence.
La méthode de votre exemple, GetCountryFromID doit être dans le projet DataAccess.
ÉDITER:
Je devrais également ajouter: il semble que vous utilisez Entity Framework (EF). Votre projet d'accès aux données doit être le seul projet contenant les fichiers EF .dll. Aucun des autres projets ne devrait savoir quoi que ce soit sur EF. Entre autres avantages, si vous souhaitez un jour échanger vos outils d'accès aux données (par exemple, quelque chose comme Dapper), ce changement n'aurait un impact que sur un seul projet.

0 commentaires

1
votes

Ce que je fais habituellement, c'est comment j'architecte mes projets:

API/MVC avec référence uniquement à mes DAL Services et DTOs

Ensuite, dans mon DAL , je l'ai divisé en deux, Commands et Queries , avec chaque action / requête / mise à jour / création sur chaque propre fichier de classe. Aussi j'ajoute leurs mes DTOs ou sur un autre projet. Et ils ne font référence qu'à mes utilitaires / services (transformation de chaîne, enum en chaîne, etc.)

Dans votre cas, je n'appellerais pas votre GetCountryById comme utilitaire ou service car il accède à la base de données et ne renvoie que la chaîne. Je le mettrais dans mes DAL>Queries car il accède à la base de données et n'en renvoie qu'une partie spécifique.

0 commentaires