I'm working on a project using entity framework 6. At the start of the project I was a beginner with EF and choose to build with EF model first.
Now the model is quite big and I’m thinking about performance and ease to change the model without dropping the databases every time.
I thinking about switching to code first.
Given that model first has already generated all the classes I need and context, I don't think it's that difficult to switch to code first.
Nevertheless I would like to know what would be the best way to do that and if there will be real advantage in term of performance and ease of model modification.
Thanks for your help,
EF 6.1 tooling now allows creating a Code First model from the database. Here is a short video and a walkthrough showing the functionality. You can download the latest EF tooling from the download center.
The code created by EDMX is not same as Fluent API although it is closed to Data Annotations.
If you would like to work with Fluent API, you can use Entity Framework Power Tools Beta 4 to generate to Fluent API from Database.
Related
I just noticed new Entity Framework Core does not provide .edmx generation any more. But I was loving this because it helps me to focus on application logic, not always create class and do migration things to update database. Now my question is- Does Microsoft have any future plan to add .edmx on Entity Framework Core? Or its permanently gone from .Entity Framework Core? I searched over internet but didn’t found any good answer for that.
I have not found any justification of this decision though I suppose this discussion can be found at least in some podcasts with EF team members interviews. In my opinion, this feature simply didn't deserve enough attention from developers and it didn't worth it to continue its support. Most people, as far as I'm concerned, moved towards code-first approach. You can concentrate on application logic even better with it, not creating any data objects in advance, but evolving your data structure together with business logic objects. That's what I can say based on my experience. Try it and maybe you will love it the same!
Edmx is not there in Entity Framework Core. It only supports a code-first approach. It produces entity class files instead of an edmx file. You can use dotnet ef dbcontext scaffold, it scaffolds a DbContext and entity types for a database.
You can refer the document to start with the already existing database.
https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db
If you are on heavy load complex database and developing application using this database continuously then there is no easier way than just press refresh button in .edmx file and get your new models ready to use. I think .edmx idea still deserves development for future. Lot of solution already made with it and continuing with .edmx
Using MVC5, EF6... We are going to build an enterprise level app. We have an existing database. Is it best to use EF code-first and code everything by hand, which takes longer, but may be cleaner? Or should we use the EF database-first approach, using EDMX (entity data model)? Can EDMX be used for enterprise level apps, or are there performance issues, etc...? What do you suggest? Thanks!
Is it best to use EF code-first and code everything by hand, which
takes longer, but may be cleaner?
IMHO, Code First is the best solution. It may take less time if you generate the Code First classes from exiting database by doing this method. You need to also know that EDMX no longer exists in Entity Framework Core verison (formely known as Entity Framework 7). Code First may help you in the future if you plan to migrate to EF Core.
Or should we use the EF database-first approach, using EDMX (entity data model)?
In my experience I encounter a lot merge conflicts when using EDMX (from Database First or Model First). If many people have to modify the EDMX in separate branchs, they will be soon be confronted with EDMX merge conflicts. Believe me, it is sometimes difficult to fix.
Hi I'm new to Entity Framework so excuse me if this question seem simple, but I have tried to find an example or question where this is described.
I have built a webApi interface with classes in what I call an eventmodell. The Interface and model is working well to receive stuff. But now I would like to build the CRUD functions to the database with Entity Framework.
I have added an empty code first model, but then I don't now how to generate csdl, msl and ssl files needed to create the database.
I have added Empty EF designer model but have found no way of adding an existing class to the designer.
I have installed EF Power Tools but that didn't help.
You seem to have a misunderstanding on how Code First works as compared to Database First.
There is no designer needed in a Code First approach. You add classes to your model, setup a DbContext and use Migrations to setup, and then at later stages, alter the database structure.
Checkout this tutorial: Getting Started with Entity Framework 6 Code First using MVC 5
I know the high-level differences between linq to sql and entity framework, however, I am hoping for advice from someone else who has already made the switch themselves, or has sufficient experience with both. Coming from a strong linq to sql background, as far as implementation and low-level details, are there any important things I need to know as I start coding my new data access layer project with entity framework?
I already created my edmx file (I chose the database-first approach), and everything just seems suspiciously identical to linq to sql so far. What would help me is a short list of items, like, in linq to sql, you do [this] [this way], but in entity framework, you'll want to do it [this way].
Sorry if this is a strange question, but any attempts at answers would be greatly appreciated. Thanks!
In new project between L2S and EF I suggest EF (consider Entity Framework version 4.0 or superior, DON'T use early EF releases).
While Linq to SQL is a class to table mapping EF 4 is a complete ORM (Object Relational Mapping) tool with different mapping scenarios.
With EF you have a lot of flexibility:
Database First approach
Model First approach
Code First approach
and a strong integration with LINQ Provider.
Unit testing with Linq2SQL is a nightmare.
With EF you have POCO (Plain Old CLR Object) classes out of the box. In L2S the entity class is tight coupled to the L2S namespace.
EF can help you also in Domain Driven Design scenarios.
Microsoft consider now EF the first database access method and it's the base for other services like RIA services or MVC database scaffolding.
LinqToSql is now the first database access methodology only in Windows Phone scenarios.
NH is far better... but again as EF is microsoft baby, it will grow as time goe
We currently have a solution that was completely written by hand in ASP.NET and MVC.
There are a lot of ugly hacks and workarounds in the DAL currently and rather than expand on these hacks, I've managed to convince the suits that we need to migrate to an ORM of some sort.
With Entity Framework experience in the team, we've decided to go with the Entity Framework, however, I have a migration question for anyone who may have had an experience with this.
Would there be any performance issues if we were to migrate Entity-by-Entity until everything was migrated to EF? What possible roadblocks (other than the obvious of having to rewrite most of the BL) could we face? Should it literally be done Entity-by-Entity (in terms of, creating the models) or would there be issues creating the entity model and just changing the BL bit-by-bit.
I can't seem to find any documentation on the subject.. MSDN seems to just say "Yay Entity Framework is good, so migrating to it is good.".
Any advice would be appreciated.
PS: I did read this: Migrating from 'native' OODBMS to ORM (Entity Framework / SQL Server)
However as we've decided to go with EF instead of NHibernate, it didn't prove very useful.
It's good question and i have a answer from my prospective. It's about 'Yay Entity Framework is good, so migrating to it is good'
Now our team is working over big (very big) HR SaaS solution. From the beginning we decided to use:
EF 4.1
MySQL (that was requirement from client)
.NET MVC 3
Then time passed (near 3 weeks) we noticed next about EF: using Model first is not applicable and useful in our system in case of hard to support system in future when we need, for example, change a little bit db structure or make new relations between tables.
In this case we moved to EF Code First (with one generic repository for all db requests). That was the risk cause it's so new technology and there was no best practices or use cases on big solutions. As result we recived a lot of other headache:
ORM made a lot of db requests (cause of a lot of relations between tables). Fixed by .Include()
Dynamic Proxy for POCO objects - made a lot of troubles, cause in code first entities from db came not like requested entity type - like dynamic proxy type. So when we tried to serialize them and put to Memcached on deserialization we get the error that this entity no more available in current context. Fixed like this: http://msdn.microsoft.com/en-us/library/dd456853.aspx and this: http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
Stupid bag with Membership that sent a lot of unbelievable requests. Fixed by reviewing our work with Membership
Also we tried NHibernate to just compare performance. NHiberanate has the same :)
General info that you should know about EF:
If you want to attache 3rd part caching be ready for workaround. NHibernate have a native integration of this
There is no big different between EF and Nh performance, but Nh have a lot of hand work with mapping
Hope i answer to your questing and info is relevant for you.
ps> sorry for my English :)