This pattern fits nicely with the SOLID principles and Separation of Concerns and keeps your code organized. It gives you a nice, clean way to separate the persistence details of your DbContext from the construction and configuration details for your DbContext. ![]() IDbContextFactory allows you to put the logic of creating instances of your DbContext into a type-safe class that follows a pattern that is known and usable by your code and the tooling of “dotnet ef”, Visual Studio, and Visual Studio Code. Well, you can’t remove the constructor and still have this work with ASP.NET Core. Either add a parameterless constructor to ‘MyDbContext’ or add an implementation of ‘IDbContextFactory’ in the same assembly as ‘MyDbContext’. ![]() No parameterless constructor was found on ‘MyDbContext’. Remove that method, and run “dotnet ef database update”. The problem is that if you get rid of the OnConfiguring() method, you’ll get an error when you try to run your EF Core database migration. Don’t hard-code your DbContext connection strings! It’s terrible for deployment and maintenance and it limits your flexibility and it’s just not a good idea (Circle slash hard-coded connection strings.) That code sample used a hard-coded database connection string in the OnConfiguring() method of my DbContext class…and that stinks. ![]() In my last post, I showed you how to set up an ASP.NET Core and Entity Framework Core solution so that you can use EF Core Migrations for database updates.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |