Entity Framework Core 1.0 Chaînes De Connexion

Nous travaillons sur une grande varient ASP.NET Core, MVC 1.0 de l'application. Nous avons 4-niveaux de chacun de nos applications comme suit:

DTO
Référentiel (Entity Framework Code First)
Service (Logique)
MVC (UI-MVC)

Actuellement, dans nos dépôts, gérer toutes les opérations de base de données, nous avons codé en dur à la base de données de chaînes de connexion dans le DbContext comme suit:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) {

    optionsBuilder.UseSqlServer("Data Source=somedatabase.database.windows.net;Initial Catalog=database;Integrated Security=False;User ID=username;Password=password;Connect Timeout=60;Encrypt=True;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False;MultipleActiveResultSets=true");

}

Ce projet est à l'extérieur de la MVC projet autonome ASP.NET Core 1.0 projet. Il dispose également d'un Programme vide.cs fichier dans ce qui semble être requis pour exécuter le code-à-base de données des lignes de commande (dotnet ef migrations ajouter et dotnet ef base de données mise à jour).

La raison pour laquelle nous avons une codés en dur chaîne de connexion dans le DbConext est parce que lorsque nous utilisons le code suivant, nous obtenons un objet de référence non définie à une instance d'un objet d'exception, lors de l'exécution de la dotnet ef commandes.

  protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) {

    optionsBuilder.UseSqlServer(ConfigurationManager.ConnectionStrings["StandardDatabase"].ConnectionString);

  }

Cependant, puisque nous avons un Programme.cs, si nous ajoutons une de Débogage.WriteLine pour la chaîne de connexion et d'exécuter le projet, il ne retour la ou les connexions de la chaîne et si nous mettons de la chaîne de connexion dans le appsettings.fichier json dans l'INTERFACE utilisateur, l'INTERFACE utilisateur va se connecter avec succès.

LA QUESTION:
La mentionnés ci-dessus de la pile est ce que nous utilisons pour plusieurs "Micro-Applications", ce qui signifie que nous avons plusieurs projets qui se connecter à plusieurs bases de données. Nous voulons aussi profiter de Développement, de Production et de transfert de chaînes de connexion.

Si nous utilisons le Gestionnaire de Configuration de la Chaîne de Connexion, tout est bon pour les opérations journalières; cependant, lorsque nous voulons utiliser Entité Cadres de code de base de données de lignes de commande, nous avons besoin d'aller à chaque dépôt que nous voulons mettre à jour et modifier le DbContext à une codés en dur chaîne de connexion, exécutez les commandes, puis les modifier de nouveau à faire, ce qui devient assez gênant.

LA QUESTION:
Sommes-nous juste de faire ce mal, est-il une pratique recommandée pour la création d'une Entité Framework Core 1.0 pile, ce qui nous permet de ne pas manuellement changer le DbContext, mais de tirer avantage des fichiers de configuration à travers le conseil d'administration?

N'importe quelle direction serait appréciée!

Il n'y a pas de MVC6 plus!!! blogs.msdn.microsoft.com/webdev/2016/01/19/...
Créer usine méthode (ou une usine de classe) qui gère les connexions et retour Dbcontext
Pourquoi n'utilisez-vous pas normal ASP.NET configuration de Base au lieu d'utiliser ConfigurationManager?
Je l'ai fait à l'origine, essayez d'utiliser le ASP.NET configuration de Base, mais a eu des problèmes de les consommer dans un fichier de classe vs un environnement hébergé. J'ai été en utilisant les lignes directrices de la docs.asp.net/en/latest/fundamentals/configuration.html cependant, je n'ai pas passé trop de temps sur ce, je vais donc essayer de nouveau. J'ai également disposer d'une unité de travail dans chaque référentiel, donc peut-être que je vais essayer de manipuler les connexions.

OriginalL'auteur Jason Martin | 2016-08-16

asp.net-core c#entity-framework-core

16

EF de Base est conçu pour être configuré via l'injection de dépendance. L'injection de dépendance maintient votre DbContext propre et indépendante de la mise en œuvre des détails de l'environnement.

Votre solution initiale de coder en dur les chaînes de connexion étroitement associée de la DbContext à la connaissance de l'endroit où la base de données est situé. C'est évidemment un problème. Mais votre solution proposée étroitement les couples de la DbContext à la connaissance d'un fichier de configuration. C'est aussi un problème.

De garder le DbContext indépendant de l'environnement de détails, créer un constructeur qui prend un DbContextOptions paramètre et appelle le constructeur de classe de base.
```
public class MyContext : DbContext
{
    public MyContext(DbContextOptions options) :
        base(options)
    {
    }
}
```
Faire cela à la place de l'annulation de la OnConfiguring. Puis l'initialiser dans le Startup.cs de votre application hôte. C'est là que la connaissance de la configuration du fichier appartient.
```
public class Startup
{
    private IConfigurationRoot _configuration;

    public Startup(IHostingEnvironment env)
    {
        _configuration = new ConfigurationBuilder()
            .SetBasePath(env.ContentRootPath)
            .AddJsonFile("appsettings.json")
            .Build();
    }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IConfigurationRoot>(_configuration);

        services.AddDbContext<MyContext>(options => options
            .UseSqlServer(_configuration.GetConnectionString("MyContext")));
    }
}
```
Vous pouvez maintenant utiliser votre DbContext à partir de n'importe où.

Comment voulez-vous l'accès du public Configuration bien d'ailleurs dans l'application, par exemple dans un contrôleur ou un filtre? Je préfère faire private et disponible à tout ce qui a besoin d'elle via le conteneur d'injection de dépendances: services.AddSingleton<IConfiguration>(Configuration);.
Je suis d'accord, @ProfK. La propriété publique devrait être transformé en un champ privé et enregistrés dans le conteneur. Pour une raison quelconque, Fichier Nouveau Projet crée de la propriété publique. Je vais changer la réponse.
question, comment utiliser DbContext importe où? peut donner un exemple simple à regarder?
La réponse n'est pas la bonne place pour une autre question. Poser votre question comme une question, laisser un commentaire, me dire où il est, et je vais répondre, si beaucoup d'autres personnes n'est pas déjà fait.

OriginalL'auteur

RÉPONSE: j'ai été ce qui en fait beaucoup plus difficile alors qu'il était réellement. J'ai suivi Juunas conseils et ajouter le code suivant dans mon Référentiel DbContext Classe:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) 
{

  //get the configuration from the app settings
  var config = new ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json")
        .Build();

  //define the database to use
  optionsBuilder.UseSqlServer(config.GetConnectionString("StandardDatabase"));

}

Qui fonctionne parfaitement avec le dotnet ef outils de ligne de commande et à mesure que les multiples configuration de l'environnement va de pair avec mon MVC de l'INTERFACE utilisateur de coller avec le code par défaut dans mon démarrage.cs fonctionne très bien aussi bien.

var builder = new ConfigurationBuilder()
      .SetBasePath(env.ContentRootPath)
      .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
      .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
      .AddJsonFile("project.json", optional: true, reloadOnChange: true);

OriginalL'auteur

IDbContextFactory peut aussi aider. EF Outils de Ligne de Commande et DI pouvez utiliser cette usine à créer des instances de votre DBContext. Moment de la conception des services (par exemple, les Migrations) découvrirez les implémentations de cette interface qui sont dans la même assemblée que les dérivés contexte.

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Infrastructure;

namespace MyProject
{
    public class BloggingContextFactory : IDbContextFactory<BloggingContext>
    {
        public BloggingContext Create()
        {
            var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();
            optionsBuilder.UseSqlite("Filename=./blog.db");

            return new BloggingContext(optionsBuilder.Options);
        }
    }
}

OriginalL'auteur

Vous devez vous connecter pour publier un commentaire.