When I read posts about db-first vs. code first approaches, I get the impression that code-first is the rising star and superior to db-first so that db-fist is about to be deprecated in the future releases of Entity Framework.
I could not find an official statement from Microsoft but they seem to be endorsing code-first by things like Identity Framework etc. Would it be a mistake to start a new project using EF DB-first?
You have EF 6 for the more traditional EF and EF 7 which became EF Core.
In my opinion you are better off focusing your effort on using EF independent from either approach.
Here's a link to an article written by EF Expert Julie Lerman.
https://msdn.microsoft.com/en-us/magazine/dn890367.aspx
Related
Is it possible to deploy / install Entity Framework Core 2.0 alongside traditional Entity Framework 6? Is it fully possible, or possible but with some hang-ups, or not possible? Is this documented somewhere? I think I've seen they said they designed it to be side-by-side, but I'm having a hard time fully confirming this. Thanks.
The official documentation says the following:
It is possible to use EF Core and EF6 in the same application. EF
Core and EF6 have the same type names that differ only by namespace,
so this may complicate code that attempts to use both EF Core and EF6
in the same code file.
If you are porting an existing application that has multiple EF
models, then you can selectively port some of them to EF Core, and
continue using EF6 for the others.
This means of course that you can install both EF6 and EF Core in the same project. I have done this in a few simple cases myself and it was working ok.
Can anyone share their experience and insights on upgrading from EF6 to EF7?
Was it straight forward? Did you discover any major benefits or drawbacks from this upgrade?
Thank you
Read this Side-by-side comparison between EF-6 and EF Core 1.0.
https://learn.microsoft.com/en-us/ef/efcore-and-ef6/features
if you need any feature which is still not done then use EF 6 because maybe you have to wait a long time.
My recommendation, if it is really not possible to use EF 6 because you have .NET Core on UWP etc, then use it, otherwise currently you can prefer to use EF 6 over EF Core this is also a recommendation from EF team you can find it on the Announcing Entity Framework Core 1.0.
When to use EF Core
We now have a Comparing EF Core and EF6.x section in our documentation. It includes guidance on when to use EF Core, feature comparisons, and information on porting to EF Core.
These are the types of applications we would recommend using EF Core for. For all other applications, you should consider using EF6.x.
New applications that do not require features that are not yet implemented in EF Core.
Applications that target .NET Core, such as Universal Windows Platform (UWP) and ASP.NET Core applications.
https://blogs.msdn.microsoft.com/dotnet/2016/06/27/entity-framework-core-1-0-0-available/
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/
We implemented a web application using EF 4.0 and ObjectContext. Now we would like to upgrade it to Ef 5 to get benefit of the performance improvements and new features, as described in Julie Lerman's
article.
From the Infrasctructure point of view, the passage seems pretty smooth:
- Target the project to .NET 4.5 (if new features like ENUM support are needed)
- Upgrade/Install EF 5
However I could not find on the net good articles speaking about the needed steps and connected risks in passing from ObjectContext to DbContext.
As for now, my approach would be to create a separate code branch and upgrade EF there. Then substituting ObjectContext with DbContaxt API and refactor arising errors.
Actually DbContext is a wrapper on top of ObjectContext developed to help developers in coding, therefore the exchange should (hopefully) be relatively smooth. We also use an interface as single point of contact to the Model, therefore this should also help to narrow down the required changes.
I am about to start implementing the data access infrastructure of a project that was architected with an approach to DDD (it's my first attempt on DDD, so be gentle ;-) ).
I will be using Entity Framework. Until now, I was looking into the method teached by Julie Lerman on her great book, Programming Entity Framework, where ADO.NET POCO Entity Generator is used, with some changes to the T4 templates and some more custom code.
Today I started reading articles on EF4.1 and the ADO.NET DbContext Generator, using Database First approach, and I'm trying to decide with which one should I go.
DbContext and EF4.1's approach on DDD seems to be a nice, cleaner way than POCO Entities, but I'm afraid that it could lead to some issues in the near future, since EF4.1 is still in RC.
From ADO.NET team blog, I know that EF4.1 does not include:
Enum support
Spatial data type support
Stored Procedure support in Code First
Migration support in Code First
Customizable conventions in Code First
From my understanding, since I will be using Database First there is a smaller number of features that were not included.
In conclusion, my question is:
Can I replace POCO Entities Generator with EF4.1 DbContext Generator?
From a point of view of clean creation of POCO entities, there is no difference between the two generators. Both generators produce the same entities, however, ADO.NET POCO Entity Generator is based on ObjectContext's API, whereas ADO.NET DbContext Generator is based on DbContext's API.
DbContext's API has a few very nice new features (Local, Query on navigation property, etc.) and API is somehow simplified but at the same time it looks like some features used in ObjectContext API are missing in DbContext API (or at least it has not been explored enough yet).
EF 4.1 RC is go-live release. It means that you can build a real application with it because API will not change in RTW (only bugs will be fixed). Also RTW should be in the next month so I think you will not be ready with your application before the final version is shipped.
ObjectContext API or DbContext API? ObjectContext API is much better covered by documentation and blog posts. You can find plenty of examples about it. Also its limitations are already well known. DbContext API is new release. A very promising release, mostly because of the code-first approach. There is still a very limited number of blog posts, no book and the API is not proven enough. So it depends if you are ready to fight with new API? If not, then ObjectContext API is still a good choice because you don't need the code-first approach.