Utilisation d'un framework d'entité pour se connecter à plusieurs tables similaires dans .net MVC

Question

Nouvel arrivant relatif à .net MVC2 et au framework d'entité, je travaille sur un projet qui nécessite une seule application web, (C# .net 4), pour se connecter à plusieurs bases de données différentes en fonction de la route d'accès (sous-domaine).

Aucun problème avec cela en principe et toute la logique est écrite pour transformer le sous-domaine en une connexion d'entité et le transmettre au modèle d'entité.

Le problème vient du fait que les différentes bases de données, tout en ayant une structure similaire, contiennent 3 ou 4 tables uniques adaptées à cette instance.

À mon avis, il y a deux façons de résoudre ce problème, mais je ne suis pas sûr que ce soit possible.

1/Utilisez un modèle d'entité distinct pour chaque base de données.
-Attempts cette route ont jusqu'à des conflits où les noms de table/sp sont les mêmes sur differnt db, ou des erreurs de conversion implicites lorsque j'essaie de mettre les différents modèles dans différents espaces de noms. 2/Remplacer les classes qui se réfèrent aux objets de base de données modifiables en fonction de la valeur d'une propriété de contrôleur de base.
-J'ai rien trouvé à suggérer je peux même faire ceci.

Ma question est de savoir si l'une des routes leser peut toujours travailler en principe ou si je devrais renoncer à l'EF et se connecter aux dtabases directlky utilisant ADO. Peut-être y a-t-il une autre façon de résoudre ce problème auquel je n'ai pas pensé?

Merci pour toute aide ...

Answer 1

Question intéressante.

Je vous recommande d'avoir un EDM séparé pour chaque base de données, et d'ajouter une autre couche (bibliothèque de classes) au-dessus du modèle (un référentiel DAL). Cette couche serait un point d'appel unique depuis votre contrôleur. Ensuite, dans cette couche, vous pouvez diriger un appel vers un contexte de données particulier et renvoyer le résultat. Vous pouvez également créer des POCO communs pour vos deux bases de données, ce qui, combiné à l'utilisation d'interfaces, vous donnera un modèle de conception solide. De cette façon, votre modèle ne sait pas à quelle base de données il se connecte - c'est le travail de votre Référentiel DAL. Lorsque vous créez votre EDMX (dans le concepteur), assurez-vous de spécifier l'espace de nommage dans la fenêtre de propriétés pour être unique, avant d'essayer d'utiliser le contexte de données.

Bien entendu, en dernier recours (si ce qui précède ne vous convient pas), vous pouvez créer des assemblages séparés pour chaque EDM et diriger un appel vers un assembly spécifique dans votre DAL.

Voici comment j'ai installé la mine (im simpliste, 'Foo' -masked termes)

J'ai une table appelée "tblFoo" sur mon EDMX.

MyApp.Model.Repository (Class Library) 
    - `Foo.edmx` (`internal`, namespace `MyApp.Model.Repository`) 
    - `ILinqRepository.cs` (defines methods such as `IList<Foo> GetFoo`) 
    - `EntityFrameworkRepository.cs` (concrete implemenation of `ILinqRepository`) 
     projects a collection of `tblFoo` into type `Foo` 
MyApp.Model.Service (Class Library) 
    - `IDataService.cs` (similar signatures to `ILinqRepository`) 
    - `LinqDataService.cs` (concrete implementation of `ILinqRepository`) 
     'greedy' constructor accepts interface `ILinqRepository` 
     and invokes methods on it 
    ie: 


public ILinqRepository _repository 
public LinqDataService(ILinqRepository repository) 
{ 
    _repository = repository; 
} 

public List<Foo> GetFoo() 
{ 
    return _repository.GetFoo(); 
} 
MyApp.Model.Entities (Class Library) 
    - POCO classes such as "`Foo`". 
MyApp.WebApplication (MVC2) 

, j'utiliser IOC (StructureMap) pour injecter les implémentations concrètes des interfaces dans le Controllers/ServiceModel.

De cette façon, il y a une approche 1-1 "pile-like":

Controller -> Model.Service -> Model.Repository -> EDMX

dans votre cas, vous pouvez ajouter une autre EDMX dans votre repository (par exemple la table est appelée tblFoo2). Ensuite, vos deux méthodes repository sont projetées à partir de tblFoo -> Foo ou de tblFoo2 -> Foo.

Vos contrôleurs ont une référence aux POCO, pas les tables (comme elles sont internal).

Vous pouvez facilement ajouter de plus en plus de fonctionnalités à votre référentiel sans toucher les autres couches. Maintenant je sais que cela peut être exagéré pour votre scénario (vous ne pouvez pas utiliser IoC - juste invoquer sur des classes concrètes), mais c'est ce qui fonctionne pour moi.

Espérons que cela aide!