The project currently I'm working on, it has been changed to fluent migrator from EF migrations. What are the benefits of fluent migrator over ef migrations? Is it really worth using over EF migrations?
EF migrations are inherently code-first - you write model first, run ef commands to generate automatic migration and then update the database. No matter how sophisticated, automatic migrations are always problematic. First, things like column renames, dropping unused columns are always problematic. Additionally, if you are using F# record types or C# POCO objects, then to facilitate migrations, you often have to decorate your plain DB entities with migration specific attributes which are not desirable.
Second, EF migrations are not easily package-able as a standalone console app. Packaging migrations into a separate executable app are always a better idea as the consumer of your application would not have worry about knowing the specific commands like entity framework migration commands. Packages like FluentMigrator and DbUp makes it very easy to package into executable. However, it depends on the application needs. For example, if you are building off-the-shelf application like open source Wordpress style blogging engine and if your audience is not well versed with .net core, then migration as a dedicated utility is helpful.
You might want to choose to run ef migrations programmatically but that again is an anti-pattern as in container world, multiple container might yield race condition and needs special care, thus always better to have separate console project for this.
Related
I am wondering about designing a EF core model of the SAP B1 database. I realize that this is a major undertaking, but I aim to start small.
This is mainly as an exercise, which may lead to something in the future.
My main issue right now, is to ensure that the DbContext is read-only.
I have found several suggestions, like this one:
How to make Entity Framework Data Context Readonly
However, that is for the Entity Framework "standard" not core, and the accepted solution does not seem to be possible with EF Core.
So, aside from using a login without write permissions, how would I go about making a read-only DbContext?
I am using EF Core 5.0.
How can I scaffold EF Core directly from a Visual Studio SQL Server Database Project?
Solutions such as the following are preferred:
scaffold-dbcontext -connection "provider=ssdtproject, name=myprojectname.sqlproj"
scaffold-dbcontext -ddl "ssdtprojectoutput.sql"
scaffold-dbcontext -ssdtschema "ssdtproject.dacpac"
maintained-third-party-tool myprojectname.sqlproj -EfModelGenerationParameters
That's the whole question. What follows is my situation in more detail, so that you may be able to offer alternate solutions:
Although MS acknowledges EF Core is still not production-ready, it's also now 3-4 years since EF 6 progress ceased, and EF Core is the only LINQ code-similar path forward with NETCore compatibility. Thus begins the saga titled "So you're going to be using EF Core."
This part is opinionated, but to me (based on 25+ years of enterprise software design and development experience) Code-First is an absolute non-starter. It's fine for small week-one application concepts, but there's no reasonable pattern/process/practice that I can see to integrate constraints, views, etc. Without views designed-in, real business apps end up with devs repeating logic fundamentals in LINQ expressions all over the place, littering the code with static fields to support LINQ-to-SQL queries, confusing micro-combinatory patterns using LinqKit, etc. Without constraints we end up with ten times the defensive code requirements to handle runtime errors, rapidly blossoming unit and integration tests, and demo failures become the norm. Either our object-oriented experts need to become SQL experts or the converse, and we drastically increase the difficulty of finding and properly-compensating engineers. All of these issues I pointed out in a detailed conversation four years ago with Rowan Miller (who recently left the EF team, which doesn't bode well for near-term solutions).
Model-First (the visual .edmx designer in prior EF versions) is obviously off the table, since the MS solution to this was to claim Code-First really IS Model-First, and wash their hands of it. Consequently a truly neutral, let's call it "Contract-First" for clarity, approach doesn't exist in EF Core.
So, that rant (sorry, frustrated) brings me to Database-First, and thus Scaffold-DbContext. Our DB Schema is currently a revision-controlled Visual Studio SQL Server Database Project. Aside some known issues with this, it also seems ridiculous to have to take our DB schema (currently our single-point-of-truth), rebuild a live database from it, and then back-generate code from the live database, all as part of our build process just to verify database type alignment. I'd like instead to be able to simply detect changes and regenerate my DbContext and related Entities directly from the Database Project.
SSDT Database Projects seem to make Database-like objects available in many of the UIs where normally database connections are required. That makes me think it may be a short walk to use the database schema as a source for existing tools. For example, use a metadata provider in a connection string, make a simple modification to the EF Core code, etc.
SQL Sharpener "generate[s] at design-time using SQL files as the source-of-truth (such as those found in an SSDT project", and was recommended as a solution to this problem for previous versions of EF, but it does not support EF Core.
SQLite and SQL Server Compact Toolbox just added support for generating EF Models directly from .DACPAC, but it appears to depend on the EntityFramework Reverse POCO Code First Generator for that functionality, which prominently lists "Support EF Core" on its TODO List. The primary contributor of this project confirms that incompatibility.
Help?
I was struggling with the same until I ran into the sublime EF Core Power Tools extension for Visual Studio. Its reverse engineering tool sounds just like what you need.
https://marketplace.visualstudio.com/items?itemName=ErikEJ.EFCorePowerTools
I'm trying to move an ASP.NET MVC 5 application to MVC 6 (ASP.NET vNext).
My existing application uses EF 6 and has some EF code first migrations. I want to port these migrations as well, because I want to be able to continue using the existing databases with the existing migrations already applied, without breaking the upgrade path.
It seems that the "new" EF Core migrations (k ef migration add ...) have quite the different format compared to the "old" EF 6 migrations:
No more Designer partial class
No more RESX file
Is there already an "official" way to upgrade these migrations? Is it supported at all? Will it be supported in the future?
There isn't really a way to do this yet. In general we strongly recommend against trying to upgrade an EF6 application to EF7 yet. EF7 is still very much pre-release.
We will have some guidance on how to do this when we get closer to RTM. We may provide some tools to help or just some guidance on how to do it.
Date: 13/April/2016
As of now it is not advisable to use EF7 in production because of following limitaions
"Because of the fundamental changes in EF7 we do not recommend attempting to move an EF6.x application to EF7 at this stage. If you want to move to EF7 to make use of new features, then make sure you are aware of the limitations of EF7 before you start. You should view the move from EF6.x to EF7 as a “port” rather than an “upgrade” ".
One area of RC1 that has a number of outstanding issues is our query pipeline. The majority of issues result in an exception when you attempt to execute a LINQ query that contains a particular pattern. There are often ways to workaround these issues by expressing the same query using different patterns, or evaluating parts of the query client-side. We try to include these workarounds in the issue, when they are available.
In RC1, there are a number of scenarios where EF7 performs slower than EF6
More Readings:https://blogs.msdn.microsoft.com/dotnet/2015/11/18/entity-framework-7-rc1-available/
Have recently been playing round with Entity Framework to see if it's suitable for our needs. So far have just been creating POCOs to create the Database and then using Migrations to update my schema (Add-Migration/Update-Database etc)
My question is, are we absolutely tied in with the Package Manager Console in order to manage the migrations?
From what I've seen so far, the only alternatives are as follows:
-Automatic Migrations (general consensus seems to be to avoid)
-Excuting Migrations in the code (would still involve using the PMC to create the Migration files, or would involve creating them by hand)
Is there anything else I've missed? It's not a big deal if we are tied in, but would just like to know for sure.
Thanks
Is there a template or tool to generate code from the database directly? I want to use model first scenario but do not want .edmx file for mappings. There is a database with many tables and I do not want to write all the classes (I am lazy) for that. So, is there a template to generate the code and set the annotations/use fluent api for defining the relationships, etc automatically from the existing database?
This would be helpful in the following scenario as well. Say, I was using .edmx with POCOs and now I do not want the mappings in the .edmx file. I want the mappings in the code. It would be great to have a tool or a template to generate the mappings in the code from the existing database.
I am starting on learning EF 4.1. I think "Code first becomes model first in version 2 i.e. after the database is created/released (in version 1) and needs some changes". Is that really true? I'd love to hear some comments. Thanks.
Check out the 'Reverse Engineer Code First' feature of the EF Power Tools CTP1 that was just released.
For generating classes, you can use POCO t4 template generation. Have a look at this detailed link which will help you getting started. That way you will get all the classes generated.
For mapping, you can use Code-Only style for Entity Framework but generating classes and context using POCO template will have far more advantage over creating the mapping yourself. Imagine adding new tables or modifying the tables, it will involve more work. But I will certainly love to know if there is any mapping tool for that.
It is possible that you are using EF-provider Devart dotConnect for Oracle when working with Oracle database. In this case the following information will help you to choose the tool.
The first version of Entity Framework Power Tools also contained the capability of generating a Code-First model with fluent mapping from an existing database. Although useful, this functionality is limited as regards its flexibility: the developer can only set the connection string; following that, classes are generated from all database objects available to the user. That is not extremely convenient, since in Oracle, for example, numerous schemas containing hundreds and sometimes thousands of tables are available to the user.
Rather than resort to this limited functionality, the users of Devart ADO.NET providers can avail themselves of impressively robust design-time development capabilities of Entity Developer, an EF-designer delivered with Devart providers. Also possible is the choice between the Database-First approach, as provided in EF Power Tools, and the Model-First approach, within which Code-First classes are created in the EDM-designer.
When compared to EF Power Tools, the Database-First approach to the development of EF Code-First models also allows selecting objects that must be available in the model, setting naming rules for the generation of class names and properties and so on. Besides, the resulting model can be modified and improved in the designer.
To better meet developers' needs, Code-First code generation in Entity Developer both for C# and VB is based on the T4-template that is easily accessible and can be modified in feature-rich T4 Editor contained in Entity Developer.
For more information on Code-First development in Entity Developer, see "Entity Developer – EF Code First DbContext Template"
http://www.devart.com/blogs/dotconnect/index.php/entity-developer-ef-code-first-dbcontext-template.html