I've searched but haven't found much on this topic. Has anyone seen a concise "order of operations" for the DBContext, including stuff like instantiation, validation, saving, etc? I'm mainly curious because while using LINQPad with my EF 4.3 Code First context, it runs two queries before any of my own. One has to do with the migration history which I understand is because we're using EF Migrations and it's attempting to see if it needs to auto-update, and another is for the EdmMetadata table which I don't understand since it sounds like that's not necessary if we're using EFMigrations.
My lack of understanding of why the one query is called makes me wonder if there are other parts of the DBContext's lifecycle that I am unaware of that might be useful to understand/override. Thanks in advance!
The query for EdmMetadata is for compatibility reasons. EF 4.1 did not have migrations. To be able to figure out whether model changed or not the EdmMetadata table was used. Let's say you developed an app using EF 4.1 app and you moved to EF 4.3 but you did not change the model. In this case there is no need to run migrations, throw exceptions or touch the database since your model has not changed. The call to the EdmMetadata table is just to be able to handle this situation gracefully and avoid throwing or touching the database if it is not needed.
I don't think there were any other changes of this kind in EF 4.3.
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.
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.
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
I used Entity framework with a database having around 50 tables and it worked just fine.
But just to see what happens with a larger database in terms of number of tables/entities i tried to implement the Entity Framework to a database that had around 100+ tables.
Once i selected all the tables and clicked on the Finish Button on the Entity Framework Wizard its just hanged my VS 2010 so i could not get any results.
My Questions are as below;
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
4.How will these different DataContext interact with each other?
5.Is there any recommended no of tables that should be used while working with Entity Framework?
#Will is correct that the limitation you're seeing is in the designer, but it's not the only one, so Code-First doesn't necessarily fix the problem.
If the designer seems slow, it's inconvenient, but not the end of the world. Runtime performance considerations are another thing altogether. For performance-critical tasks and tuning, you'll want to understand the whole pipeline.
View generation, e.g., takes time. You can move this to compile time with manual work.
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
I certainly wouldn't let it stop you.
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
That's certainly a good approach for many applications.
4.How will these different DataContext interact with each other?
Mostly not. A single, giant data model is often a bad idea due to service coupling. However, you can selectively couple them by sharing portions of the models with includes in EDMX or classes in code-first.
5.Is there any recommended no of tables that should be used while working with Entity Framework?
One way is to use smaller models, as you've suggested. Another way is to work around the runtime performance issues which sometimes come with larger models (see the links I give above). Like any potential performance "problem", write correct code first, then profile and fix the slow parts. Usually, query tuning is more important than model size anyway.
EF, probably yes. The toolset in Visual Studio? Not so much, apparently. For a database this big, you might want to do Code First.
I think EF itself have't performance limitations for count of tables, but have for count of records in particular table. You have to do manual object-db relation (i.e. manual write classes for tables and corresponding attributes) for go away from design problems in VS10.
It's clear approach in Hibernate, but in EF probably not.
Entity Framework is the best way to develop database applications.
I used to develop my applications using LINQ to SQL but since Microsoft is not going to support it in future, it recommends to use Entity Framework.
By the way, Entity Framework 4 in .NET 4 has much better performance than previous versions.
I'm currently developing an enterprise application using Entity Framework and it supports all my needs.
I suggest to use Entity Framework.