2010-12-05 23 views
0

Je veux juste enfin envelopper ma tête autour des membres statiques/non-statiques pour de bon. J'utiliserai mon application ASP.NET MVC 2 + Ninject + Repositories + Provider + Entity Framework dans mes exemples. Donc, en supposant que je lie une instance singleton de mon conteneur EF dans le noyau Ninject, si j'ai ce code, verrai-je des améliorations de performance, ou comment cela sera-t-il affecté?Question générale sur les membres statiques, et en relation avec DI sur les dépôts et les fournisseurs

public class Repository<T> where T : class { 
    // private readonly DefaultContainer = null; 
    // REPLACED BY: 
    private static readonly DefaultContainer = null; 

    [Inject] 
    public Repository(
     DefaultContainer DefaultContainer) { 
     DefaultContainer = DefaultContainer; 
    } 
} 

public class EmployeeRepository { 
    // private readonly DefaultContainer = null; 
    // REPLACED BY: 
    private static readonly DefaultContainer = null; 

    [Inject] 
    public EmployeeRepository(
     DefaultContainer DefaultContainer) { 
     DefaultContainer = DefaultContainer; 
    } 
} 

Dans les deux référentiels ci-dessus j'ai un membre privé de DefaultContainer qui est par défaut à null, puis injecté dans le constructeur où il est définitivement fixé.

Maintenant, y a-t-il une amélioration des performances si elle est statique par rapport à non statique? Je demande parce que en lisant MSDN, j'ai lu que les membres statiques ne sont alloués qu'une seule fois, donc est-ce que cela signifie que je peux avoir 20 dépôts dans un fournisseur et tous utilisent exactement le même DefaultContainer? Ou, cela signifie-t-il que la première instance de Repository<T> allouera DefaultContainer, mais tous les référentiels suivants de T, où qu'ils soient créés dans l'application, utiliseront ce ?

Si c'est la première option, cela n'augmenterait-il pas les performances de l'application puisqu'il y a un objet utilisé par tous?

Si c'est la deuxième option, alors il n'y aurait pas aussi une augmentation de performance, même si elle est allouée une fois pour chaque Repository<T> plutôt que pour chaque Repository<T>?

J'apprécierais que quelqu'un me fasse la lumière. Je pense que je comprends, mais j'ai juste besoin de quelqu'un pour clarifier pour moi.

Répondre

3

Réponse courte: non, il n'y a pas un avantage de performance. Réponse longue: En utilisant un champ static, vous perdez la responsabilité de maintenir le style de vie de votre dépendance. Les conteneurs comme Ninject ont généralement l'option de résoudre quelque chose comme singleton ou transitoire. Si vous décidiez que votre dépôt (et DefaultContainer) devrait être transitoire plutôt que singleton, mais qu'il y avait toujours le champ statique, vous seriez confronté à une condition de concurrence plutôt désagréable car les instances écraseraient successivement le champ partagé.

+0

Je vois, je me demandais à l'envers de la façon dont les objets que Ninject garde en ligne de compte sur les objets que Stoject surveille, et vous avez à peu près répondu à cette question. . – Gup3rSuR4c

2

Je recommande de supprimer les membres statiques et de laisser votre conteneur ioc gérer la durée de vie de l'objet. J'ai récemment fait une série de billets de blog couvrant une grande partie de ce même terrain. J'ai utilisé nhibernate au lieu de framework d'entité. Voici un lien qui peut intéresser:

http://blog.bobcravens.com/category/ninject/

Hope this helps.

Bob

+0

Parcourez vos entrées, plutôt jolies infos. J'aurais aimé avoir trouvé ça la première fois que j'intégrais Ninject. : ( – Gup3rSuR4c