Dans mon application ASP.NET MVC, j'ai un projet contenant toute la couche logique / service d'entreprise. Ce projet interagit avec ma base de données (cadre d'entité) qui est situé dans un projet séparé.
Je voulais un accès facile à la couche de service, donc j'ai créé des classes statiques afin de pouvoir être référencées facilement. Par exemple, si je suis dans mon contrôleur et que je dois créer un nouveau compte: p> La couche de service est alors toute la logique requise, crée ensuite l'utilisateur via le référentiel dans la base de données code>. p> car je ne voulais pas faire ce qui suit partout dans ma couche de service: p> public class AllRepos
{
private AccountRepository _Accounts;
public AccountRepository Accounts
{
get
{
if (_Accounts== null)
_Accounts= new AccountRepository();
return _Accounts;
}
}
// the same is done for every other repository (currently have about 10+)
}
4 Réponses :
Je ne suis pas sûr de savoir pourquoi vous êtes si mort-à-propos de l'utilisation des instances. Outre le fait que le code que vous avez maintenant est inutilement compliqué, l'utilisation de types statiques facilite également le test de l'unité. Le type statique est comme un singleton que vous ne pouvez pas vous moquer / remplacer. Il me semble que votre vraie question pourrait être "Comment puis-je gérer des instances à vie de ma couche de service?" En règle générale, vous le faites en ayant une instance par demande Web. Dans une application ASP.NET MVC, vous pouvez Nouveau sur un conteneur DI via une conférencière et gérer tous les Ceci. [pdf]
Votre approche à ce sujet n'est vraiment pas une recommandée. Personnellement, je n'autoriserais jamais ce type d'approche sur mon équipe. Les inconvénients:
La plus grande raison de créer des instances de référentiels est de pouvoir injecter les dépendances si vous en avez besoin. L'argument le plus connu pour cela concerne les tests unitaires afin que vous puissiez se moquer des dépendances, mais j'ai construit un certain nombre de référentiels qui ont des dépendances d'interface qui changent de code de production.
Vous devez simplement faire votre instanciation de votre référentiel dans le cadre de vos cours de service de base de toute façon. Il n'y a aucune raison que cela doit être "statique ou instance appelle partout". Il devrait y avoir une instance limitée code d'instanciation dans les classes de base.
J'aimerais également ajouter que j'ai rencontré des problèmes d'escalade à MSDTC lors de l'utilisation d'une classe statique entre le contrôleur et le service.
Vous devez gérer la portée de votre objetContext de manière délibérée, comme faire un Unité de modèle de travail
En dehors de cela, je pense que vous devriez vous reconsidérer tout statique, car Womp dit que vous obtenez un accouplement très élevé et le rend très difficile à tester, et vous pouvez obtenir beaucoup d'aide pour gérer le graphique de dépendance en utilisant un Conteneur IOC.
Je peux dire cela, après avoir brûlé moi-même faire ce genre de chose précédemment :)
singletons (et classes statiques comme décrit) sont diaboliques et doivent être évités à tous les coûts, en particulier dans les applications Web.
Je ne suis pas d'accord avec cela, les méthodes d'assistance sont idéales lorsque statiques. Enfait certaines des meilleures méthodes d'assistance sont statiques pour une utilisation sur le Web. Demande, serveur.mappath, fichier / répertoire, etc.
"En fait, certaines des meilleures méthodes d'assistance sont statiques" Quelle est votre concept de "meilleur"?