J'essaie d'injecter une dépendance en obtenant la configuration en classe dans le projet de base .NET. La classe où j'essaie d'injecter une dépendance est dans un autre projet. Mais d'une manière ou d'une autre, je ne suis pas capable d'obtenir les valeurs du fichier de configuration dans une dépendance injectée. Vous trouverez ci-dessous mon code
dans ci-dessous DBContext, je dois obtenir de la valeur à partir de la configuration, où j'ai utilisé une classe DI de dbconfiguration. P> et mon fichier startup.cs dans web API P> {
"DBConfiguration": {
"ConnectionString": "Server=myserver;Database=BaseProjectDB;Trusted_Connection=True;MultipleActiveResultSets=true",
"ApplicationName": "WebAPI"
},
"Logging": {
"LogLevel": {
"Default": "Warning"
}
},
"AllowedHosts": "*"
}
3 Réponses :
Vous semblez utiliser dbconfigurationOptions dans votre fichier de démarrage, tandis que vous injecte dbconfiguration dans votre dbcontext.
Voici comment j'utilise actuellement ma configuration: p>
public class DBContext : DbContext { private readonly DBConfigurationOptions _dBConfiguration; public DBContext(IOptions<DBConfigurationOptions> dBConfiguration) { _dBConfiguration = dBConfiguration.Value; } }
Oui.
Je ne suis pas tout à fait certain (cela fait longtemps que j'ai mis en place quelque chose comme ça et je n'ai pas utilisé de cadre d'entité dans Forever), mais vous devriez peut-être déplacer la configuration dans votre démarrage au-dessus de l'addition de SQL Server. De plus, je vais modifier ma réponse avec un exemple de la manière dont nous utilisons la configuration, comme cela pourrait être utile.
Pour recevoir la configuration, vous devez modifier la signature de votre constructeur dans à p> Pour recevoir correctement l'option (N'oubliez pas d'ajouter l'espace de noms En outre, vous devez définir la classe dbcontext code> à partir de
Microsoft.extensions.options code>). P>
dbconfiguration CODE> quelque part avec les propriétés que vous avez dans votre fichier de configuration. p> p>
Mais nous ne pouvons pas l'utiliser sans interface IOPTIONS?
Je ne le pense pas. Si vous ajoutez les options à la collection de services via services.configure code> vous les recevez via
ioptions code> interface. C'est la façon dont il est conçu.
Pourquoi ne configurez-vous pas le DB directement dans l'endroit où vous avez également la configuration?
Dans votre classe DBContext (BTW, vous devriez probablement choisir un meilleur nom pour cela) Il vous suffit de révéler un constructeur comme celui-ci, pas besoin de remplacer la configuration ou quoi que ce soit comme ça.
Cette classe peut être dans n'importe quel assemblage que vous souhaitez. p> Pour la configuration, vous pouvez simplement utiliser OptionsBuilder-Action intégrée (Place à l'intérieur du ConfigureServices Méthode): P>
var DBConfig = Configuration.GetSection("DBConfiguration").Get<DBConfiguration>();
services.AddSingleton(DBConfig);// <- now you can inject that if you want but it's not necessary
// now we don't need to get the config here
services.AddEntityFrameworkSqlServer()
.AddDbContext<DBContext>(optionsBuilder =>
optionsBuilder.UseSqlServer(DBConfig.ConnectionString)
);
Merci pour l'aide ! La raison pour laquelle je vais comme ça, j'essaye de faire du dal qui aura des fonctionnalités communes réalisables déjà disponibles afin que je puisse utiliser le même dal dans le nouveau projet que