Modèle de base de données Factory avec plusieurs bases de données

Question

Je crée un modèle de fabrique de base de données pour une application qui devrait pouvoir fonctionner avec SqlServer et Oracle. Je l'ai utilisé une approche similaire proposée dans l'article suivant:

http://www.primaryobjects.com/CMS/Article81.aspx

Maintenant, le problème est que mon application communique avec plusieurs bases de données sur le même serveur. Par exemple: J'exécute peu de requêtes sur la base de données DB1 et peu de requêtes sur DB2, à la fois sur SqlServer. En utilisant l'article ci-dessus, je pourrais créer une instance d'une base de données. Comment puis-je utiliser la même approche pour travailler avec plusieurs bases de données. Quelqu'un peut-il m'aider avec ça? Merci.

Answer 1

Je vous suggère de jeter un coup d'œil au modèle de dépôt. Avec l'utilisation d'un modèle de référentiel, vous pouvez extraire votre application de l'infrastructure. Cela vous permettrait alors de communiquer avec une ou plusieurs bases de données, services Web, le système de fichiers ou toute autre source de données qui est en dehors de votre domaine et du contrôle direct des applications. Avec cela, vous pourriez avoir une infrastructure qui dans les coulisses peut communiquer avec plusieurs sources de données. Un exemple de ceci était une application de commerce électronique sur laquelle j'ai travaillé récemment et qui m'a permis de parler avec ma base de données locale pour le catalogue de produits direct, mais aussi avec SAP dans les coulisses pour enregistrer de nouvelles commandes/achats.

Avec cela, vous pourriez avoir un code qui appelle dans le référentiel qui ressemble à ceci:

AccountRepository _repository = new AccountRepository(); 
Account account = _repository.GetAccountByID(32); 

Ou vous pouvez dire quelque chose le long des lignes de:

Account account = new AccountRepository().GetAccountByID(32); 

L'idée de base derrière un référentiel est que votre application peut faire des appels pour obtenir les données dont elle a besoin. Cela renverrait des objets de domaine réels (tels qu'un compte dans l'exemple ci-dessus). Ou il pourrait retourner IEnumerable<Account> si une liste de comptes est nécessaire.

Une mise en œuvre de celui-ci où vous prenez les données de deux sources de données pourrait ressembler (bien que je ne suggère pas de préoccupations co-mingling comme celui-ci):

public class AccountRepository 
{ 
    public Account GetAccountByID(int accountID) 
    { 
     Account result = null; 

     using(MyDataContext dc = new ConnectionFactory.GetConnection(Databases.DB1)) 
     { 
      result = dc.Accounts.Where(a=>a.AccountID == accountID).FirstOrDefault(); 
     } 

     //result is null...go to the other database to get an Account 
     if(result == null) 
     { 
      using(MyDataContext dc = new ConnectionFactory.GetConnection(Databases.DB2)) 
      { 
       result = dc.Accounts.Where(a=>a.AccountID == accountID).FirstOrDefault(); 
      } 
     } 

     return result; 
    } 
} 

Ma préférence pour une situation telle que ce serait pour créer une couche de service d'application qui gère la logique d'application. Un référentiel devrait techniquement être concerné par une source de données. Vous pouvez alors avoir un référentiel différent pour les différentes sources de données du couple. Dans votre couche d'application, l'instance de GetAccountByID du référentiel 1 (base de données 1) serait alors ajoutée et, si elle était nulle ... la couche d'application serait alors plongée dans le deuxième référentiel (base de données 2 par exemple). Le référentiel devrait suivre les principes SOLID si possible. Là où mon exemple brise clairement l'approche SOLID, c'est qu'il y a plus d'une raison pour que cette implémentation de GetAccountByID change!

Mais ... si c'est ce dont vous avez besoin ... il y a un moyen de le faire!