2

J'ai une application qui utilise ORM (Nhibernate mais ce n'est pas le cas).Injection de dépendances et données spécifiques à l'utilisateur

Pour créer session NH nous avons besoin de passer quelque part: nom d'utilisateur, le nom de base de données, etc. J'ai donc mis en œuvre:

public interface ISettingsManager 
{ 
    Settings MySettings {get;set;} 
} 

public class Settings 
{ 
    public string DbUser{get;set;} 
    public string DbAddress {get;set;} 
    public string DbPassword{get;set;} 
    //... 
} 

public class SessionProvider 
{ 
    [Inject] 
    public ISettingsManager MySettings {get;set;} 

    public Session CreateSession 
    { 
     //Create Session object using settings passed do MySettings via IoC. 
    } 
} 

public static Main() 
{ 
    // very beggining of my application, bootstrap the DI container 
    Bind<ISettingsManager>().To<SettingsManagerImpl>(); 
    // Application run 
} 

Tous mes NHibernate session fournisseurs ont le ISettingsManager injecté via DI (Ninject) afin Je peux l'utiliser simplement. Cela fonctionne comme un mal, mais maintenant je dois supporter de nombreux utilisateurs dans mon application et le problème entre dans la scène. Donc, la question est de savoir comment implémenter les paramètres de l'utilisateur actuellement connecté de la meilleure façon, sans utiliser l'emplacement de service?

+1

Je suppose que vous vouliez dire comme un charme et pas comme un mal, malgré la source violente pour le nom ninject :-) –

Répondre

1

En supposant que j'ai bien compris le problème, quelque chose comme le modèle singleton pourrait aider (voir http://en.wikipedia.org/wiki/Singleton_pattern).

Un singleton stockerait l'information et la donnerait sur demande. D'autres composants auraient besoin de savoir seulement comment accéder au singleton, rien de plus spécifique.

Pour obtenir des paramètres utilisateur individuels sur le singleton, un type de dictionnaire de structure de données qui mappe des clés (comme l'ID utilisateur) sur des valeurs peut être bon.

+0

Après avoir joué avec cela Singleton introduit Service Location, mais oui - c'est une solution. – Dariusz

1

J'utiliserais un DB distinct pour toutes les authentifications, puis retirerais les paramètres DB spécifiques à l'utilisateur de ce DB. En utilisant le paramètre spécifique à l'utilisateur récupéré, je créerais la classe que vous voulez injecter dans le processus de connexion de votre ORM et l'injecterais en utilisant l'injection de constructeur ou de propriété.