Voici mon scénario:
J'ai une seule application, mais je dois changer la connexion à la base de données par route.
Exemple:
switch(route)
{
case(URL/A):
{
USE DATABASE 1
}
case(URL/B):
{
USE DATABASE 2
}
DEFAULT:
USE DATABASE DEFAULT
}
Est-ce possible?
3 Réponses :
Vous pouvez créer 3 chaînes de connexion et 3 classes d'accès aux données. Le premier de votre classe utilise par exemple DropCreateDatabaseIfModelChanges, d'autres utilisent CreateDatabaseIfNotExists. Lorsque vous appelez la première classe, votre base de données crée lorsque vous en avez besoin, il n'est pas nécessaire de la recréer.
Dans un contexte de référentiel. Veuillez ne pas faire cela au niveau du contrôleur. Créez un référentiel pouvant prendre différentes configurations et facilement échangeable par DI
Enregistrez votre contexte (selon la portée, par requête) et utilisez la méthode de fabrique pour créer dynamiquement le contexte avec la chaîne de connexion spécifiée en fonction de l'itinéraire actuel (qui devrait être disponible à partir de HttpContext ou quelque chose de similaire). Si les schémas de bases de données sont identiques et que seules les données sont différentes, cela devrait fonctionner facilement. Je ne peux pas vous fournir d'extrait de code car cela dépend principalement du framework DI dont vous disposez.
Puisque vous utilisez ASP.NET MVC, vos itinéraires dépendent de vos contrôleurs. Ensuite, vous pouvez imaginer avoir ControllerA utilisant DatabaseA et ControllerB utilisant DatabaseB.
Pour utiliser plusieurs connexions de base de données, vous avez besoin d'une chaîne de connexion pour chacune d'entre elles.
J'utiliserais les morceaux de code suivants pour injecter instances de DbContextOptionsBuilder dans Startup.ConfigureServices ()
public ControllerA(IConfiguration configuration,
IMemoryCache cache,
IHttpContextAccessor contextAccessor,
DbContextOptionsBuilder<ContextA> ContextAOptionsBuilder,
DbContextOptionsBuilder<ContextB> ContextBOptionsBuilder)
:base(configuration, cache, contextAccessor, ContextAOptionsBuilder,ContextBOptionsBuilder)
{
//Create your DbContext using the builder
}
Ensuite, vous pouvez configurer vos générateurs de cette manière (en fonction de vos paramètres)
public BaseController(IConfiguration configuration, IMemoryCache memoryCache,
IHttpContextAccessor contextAccessor,
DbContextOptionsBuilder<ContextA> ContextAOptionsBuilder,
DbContextOptionsBuilder<ContextB> ContextBOptionsBuilder){}
Bien sûr, ControllerA et ControllerB étant les classes héritières de BaseController, vous pouvez accéder au constructeur souhaité tout simplement.
ContextAOptionsBuilder.UseSqlServer(Configuration.GetConnectionString("ContextAConnectionString"), builder =>
{
builder.EnableRetryOnFailure(5, TimeSpan.FromSeconds(30), null);
});
ContextAOptionsBuilder.EnableSensitiveDataLogging();
De cette façon, vous pouvez utiliser l'une, l'autre ou les deux bases de données pour construire votre contexte
Une manière plus simple aurait été d'injecter votre fichier de configuration et de construire votre contexte à partir de son contenu, mais le commentaire de ppumkin suggère que c'est une mauvaise idée de faire t le sien au niveau du contrôleur.
Cette solution fonctionne pour moi dans une application ASP.NET Core MVC, j'apprends toujours le framework mais peut-être que ma réponse vous a donné des précisions sur plusieurs DbContexts.
Trois ouvrants
{mais seulement deux fermant}dans votre extrait de code.Réponse simple, oui, mais il y a beaucoup de pièges associés à cela. Les deux entités sont-elles identiques? Est-ce seulement la connexion qui diffère?
Ouais Peter, toutes les entités sont les mêmes, seules les données sont différentes
Uwe Keim, c'est normal dans un boîtier de commutation.
Peter, comment puis-je faire ça?
Comment créez-vous votre contexte en ce moment? Utilisez-vous DI?
nouveaumanuellement?David, j'utilise DI
Cela peut nécessiter une forme d'héritage, mais ce n'est pas quelque chose que j'ai jamais tenté.
Utiliser le modèle de référentiel et DI
Enregistrez votre contexte et utilisez la méthode de fabrique pour créer dynamiquement un contexte avec la chaîne de connexion spécifiée en fonction de l'itinéraire actuel. Si les bases de données sont identiques et que seules les données sont différentes, cela devrait fonctionner facilement.