est-il possible d'enregistrer le même contexte de DB avec deux chaînes de connexion différentes dans le noyau .NET? Et, utilisez l'un de ces 2 contextes en fonction de ce qui est passé dans l'en-tête.
merci!
5 Réponses :
Vous aurez besoin de deux dBcontexts. et vous pouvez ensuite les enregistrer comme ceci: bonne chance. Bonne chance.
> Vous êtes censé avoir besoin de deux dBContexts, hein? Que veux-tu dire par là?
Non, vous n'avez pas besoin Deux classes DBContext différentes pour utiliser différentes chaînes de connexion. C'est une solution , mais loin du mieux.
Si vous pouvez le faire, faites-le et aidez-le.
J'ai rapidement mis ensemble ce code. Non testé, pourrait avoir besoin de modifications pour travailler. Le point principal est de ne pas utiliser l'enregistrement de DI standard, mais utilisez votre propre usine pour créer le contexte.
public class Controller
{
private readonly DbContextFactory _dbContextFactory;
public Controller(DbContextFactory dbContextFactory)
{
_dbContextFactory = dbContextFactory;
}
public string Endpoint(string apiParameter)
{
using (var context = _dbContextFactory.Create(apiParameter))
{
// use context here
}
}
}
La question est de savoir comment passer Différentes chaînes de connexion pour chaque demande en fonction de certains critères. Vous devez supprimer cela puisque vous avez déjà posté une réponse pertinente
La question n'est pas vraiment claire, alors supposons que le problème réel accède à une base de données multi-entreprises. Gunnar Peipman a écrit Plusieurs articles et présentation sur la manière de mettre en œuvre la multi-location dans ASP.NET CORE, et une spécifiquement pour Base de données par locataire et ASP.NET CORE Les fournisseurs de locataires .
La solution est en fait très simple - avoir le Contexte Demandez la connexion correcte via un service injecté: Ceci déplace le problème de la détection du locataire à tout ce qui reste est enregistré tous les contextes et dépendances. Encore une fois, rien de spécial: ItéNantProvider un en-tête HTTP. C'est facile à faire aussi - créer une classe qui accède à httpContext via une dépendance IHTPContexTAccessor. Cela peut être aussi simple que:
Bonjour, qu'est-ce qui sera "connexion" dans startup.cs? services.adddbcontext
@RocketsingH Quelle que soit la base de données que vous souhaitez utiliser pour stocker la configuration du locataire. Ce n'est pas la partie importante, cependant, vous pouvez utiliser n'importe quel type de stockage que vous souhaitez stocker les données du locataire. Demandes-tu à propos de la multitabilité alors? Vous devriez mettre à jour la question et faire ce spécifique
Laissez-moi essayer, ce que vous avez suggéré. En regardant là maintenant
Si toutes les informations dont vous avez besoin pour choisir la chaîne de connexion à utiliser est en-tête, c'est la solution la plus simple:
// needed below
services.AddHttpContextAccessor();
// register DbContext with options that change depending on request's header
services.AddDbContext<DatabaseContext>((provider, builder) =>
{
// get current HttpContext
HttpContext context = provider.GetRequiredService<IHttpContextAccessor>().HttpContext;
// get relevant header
var headerValue = context.Request.Headers["user-agent"].Single();
// create relevant connection string based on header value and configure context to run against SQL Server
var connectionString = CreateConnectionString(headerValue);
builder.UseSqlServer(connectionString);
});
//// one of safest way as DbContext is not thread safe
List<Model> Items;
await using (var _dataContext = new DataContext(connectionString:"connection String"))
{
Boughts = await _dataContext.YourModel.ToListAsync();
}
Différentes chaînes de connexion?
Oui. Nous devons 2 dB avec les mêmes tables et tout. Il s'agit simplement de celui basé sur certains paramètres, les données doivent être envoyées à différentes instances. @ Schwarzie2478
Je pense que vous avez besoin de deux dB contexte pour cela. (99% sûr) Comment un modèle resterait-il cohérent s'il n'a pas toutes les modifications que vous avez faites? Je ne pense pas que c'est le meilleur moyen de séparer ces instructions (ce que vous voulez probablement). Soit cela dans votre logique commerciale ou au niveau de la base de données (s'ils peuvent se parler les uns avec les autres) déclenchent, Procs stockés, vue.
@ Schwarzie2478 Vous voulez donc avoir besoin de 2 classes de contexte, contextone et contextwo? Ensuite, j'enregistre ces 2 instances dans le démarrage. Et puis dans ma couche d'entreprise, je dois injecter ces deux cas et utiliser l'un d'entre eux en fonction de certains paramètres.
Oui, c'était ce que je pensais aussi. C'est ce que vous faites avec différents modèles, mais il peut être utilisé de la même manière pour le même modèle avec des connexions différentes ...
Oui, je veux utiliser 1 contexte mais comment dépend de la dépendance injecte le bon contexte (avec chaîne de connexion) en fonction des données transmises dans l'en-tête @ schwarzie2478
Laissez-nous Continuer cette discussion en chat .
"basé sur ce qui est passé dans l'en-tête" - avez-vous une base de données par client?
@Rocketsingh Quel est le problème réel ? Vous pouvez facilement transmettre différentes chaînes de connexion au constructeur. Les dBcontexts sont censés être courts de courte durée de sorte que vous n'avez besoin de rien d'autre. DI n'est pas une préoccupation, il suffit de passer la chaîne de connexion correction dans le
adddbcontext en fonction des critères que vous utilisez pour cela - que vous n'avez pas expliqué. Vous pouvez aller aussi loin que de créer votre propre middleware pour créer des dBContexts en fonction des critères souhaités.@Rocketsingh Tu ne nous ai pas dit ce que tu faire veux encore - essayez-vous de mettre en œuvre une application multi-entreprises? Il y a Beaucoup façons de pour cela, en utilisant une seule base de données et des filtres de requête EF, différentes bases de données par locataire ou une combinaison de bases de données partagées et isolées. De nombreux articles expliquent comment faire cela aussi, comme Celui-ci