I'm just starting to learn EF and now readind about Code First workflow. From what I gather, you would design your objects first and then the database would be created based on those objects. I can't seem to see the good in this. Why would you let your database schema be dictated by the hierarchy of your objects? Would you be able to optimize your database using Code First?
Also, as I have not read far enough yet, does Code First fully support DBMS features (indexes, triggers, sp, etc)? I ask as I've read in some articles that this is what most preferred (Code First). I have seen something about Code Second which is from what little I've read, I think is much better (existing database, but code centric development?), but maybe I'm missing something or haven't yet read enough and you guys can clear those things up. Thanks.
The capabilities of code first are the same since you have the same ability to express all the features of EF manually in your code. The main difference is that you don't use a designer to generate your EF code. This offers some benefits since you can decouple your entity classes from the EF context. The main benefit of this is that you can use plain old c# classes that aren't necessarily tied to EF if you decide to switch to another orm down the line.
The downside of course is that you have to hand code the entire model.
Keep in mind that you don't have to generate the database from your code. You can code against an existing database.
Related
I'm working on an application that interfaces with a slightly odd database. The design of this database is pretty bad; there are basically no foreign keys (although there are columns that reference other tables, they're not set as keys), columns are named very ambiguously, and the structure does not lend itself to the kind of logic I'm aiming to do (mostly, it forces joins for operations that should be simple, and leaves you trawling through needlessly massive tables for things that could have been split).
Unfortunately, I'm stuck with this database. It's being replicated off a third-party system, so I can't change the table structure or anything. I can add stored procedures and views, though.
In the application, I've come up with a set of classes that I can work with much more easily. I've got quite a bit of experience with Entity Framework, so I'm planning to use that. My initial hunch is that I can add views to the database that return things in the format of my classes, and then from there on out just pretend that they're tables. I've never tried anything like this before, though, and I'm not entirely sure how to proceed.
How can I use Entity Framework to map my classes to these views? Note that it kinda needs to be my POCO classes, rather than anything EF auto-generates - is there a way to tell EF to map existing classes?
If you use code first then Entity Framework will generate CreateTable instructions in the migrations. To use a view instead, replace this code with your own Sql to generate the View. See the answer to this question: Mapping Database Views to EF 5.0 Code First w/Migrations
I would also configure Entity Framework to use stored procedures. Then you can tailor the insert/update/delete sql to match the underlying tables. Again, you can do this by altering the sql that is generated for you in the migrations.
I'm bit confused: with all the evolutions of EF i'm not sure where i'm now.
*Is EDMX a choice of the past and should be used any more ?
*If so what is the best choice ?
*I hate edmx, can i upgrade to code first ?
It is not clear what all this EF versions are to me
Thanks
Jonathan
For a lot of apps you can start using Code First if you want to. The one big thing Code First doesn't support yet is mapping to stored procedures. (You can still call stored procedures, but you can't map entity CRUD operations to them.)
That being said, doing Database First with an EDMX is still absolutely supported and a fine choice, especially you like using the EF designer.
EF 4.1 and above fully support both Code First and Database First.
Personally, I would almost always choose Code First, even with an existing database, because I'm a code-centric person and would rather keep all my mappings in code where I can easily refactor, manage in source control, split into multiple files, etc. For me, it's much easier and nicer to deal with code artifacts than monolithic XML documents.
This is how you should evaluate your Entity Framework usage:
1) EDMX is a totally valid option specifically if you have an existing Database and want to generate your entities based on your database schema. One of my favorite benefits to this can be rapid data layer development with low risk. Also mapping stored procedure results to classes is always nice when you have complex existing stored procedures to work with.
OR
2) Code First is a totally valid option specifically if you want to create you database based an object oriented data model. With code first its easy to make big refactors that you don't always think of till implementation time. Source control is more common with code and shelving/rolling back are beautiful features.
TL;DR version :
They are both totally viable options. Neither are outdated ;nor shall they be any time soon.
We had performance consideration in warm up EF Code First. EF Code First take some minutes to start, because we have thousand Entity. so this bottleneck enforced us to Use EDMX, and used Interactive Pregenerated to Create EDMX from Code First in First Run after entity Model changed, and at Other First Run warm up time considerably lowered.
but story not end at that. after doing that we saw in Development area we have many change in Entity Model, so after each change EDMX File should be recreated(update) very often. so we decide to Create EDMX Programatically and Optimize that creation for our Entity Models.
We're currently a Linq to SQL shop but evaluating Entity Framework. One thing that always frustrated me with L2S is how messy the DBML canvas became after putting more than say a couple dozen tables on it. It just became one large mess.
I'm wondering if EF handles this any better? What would be ideal (for us) is the ability to have a separate EDM for each of our schema's. That would keep things very neat and tidy. However, I don't know then how we would establish relationships across EDM's.
Can anyone tell me how (or if) EF handles this sort of thing?
Just my 2 cents.
I deeply recommend you to throw away dbml and edmx as well, and move to EF 4.1 code first. It will give you all the power and flexybility you need.
For me it was a no turning back ever. You can find excellent posts of Scott Guthrie about it if you google a little.
Handling this in EDMX is possible but still it is far away from nice or ideal solution especially because it is not supported by designer - you will work with EDMX as XML. Also relations can be only one way, bidirectional relations between EDMX are not supported. ADO.NET team described the whole process on their blog.
If you have separate schema for some set of tables then tables probably represent some separate business domain where the connection to other schemas are not so common. Perhaps isolating the schema in completely separate model (EDMX) can be way to go.
Trying to wrap my head around the best approach in modelling a database when we are using Entity Framework 4 as the ORM layer. We are going to use asp.net mvc 2 for the application.
Is it worth trying to model using the class diagram modeller that comes with Visual Studio 2010 where you graphically configure your models into the EDMX file and then generate out the database structure?
I have run into a bunch of non trivial issues and for complex many to many mappings or multi primary key entities the answer is not that obvious even after poking around a while with the tools.
I figure its easy at this point to give up and start modelling the DB using real, working DB modelling tools and then try to generate out the EDMX from the database, rather than trying to do the model first approach.
It's really a matter of preference. If you are comfortable in SQL server that's probably the best place to start. But if you are more of a C# programmer, it's sometimes easier to start in the EDMX designer, make the model and then ask it to figure out what the database should look like.
Of course if you do go model first you'll still need to go in to SSMS and add indexes and maybe rename some FKs and tables more to your liking. Then you can bring the model back up to date with an Update from Model.
Modelling inheritance is also something you'll need to do in the designer, but again you can either do it in SSMS or in the EDMX designer. For inheritance I mostly prefer SQL first because there is the explicit decision as to what form of inheritance you want - per hierarchy, per class, or per concrete type.
I am starting with the Entity Framework. It sounds great. But I am wondering if I should watch out for some weakness somewhere. Any experience there?
You probably need to start prefixing these questions with the version you are talking about. A good amount of the annoyances have been fixed in the upcoming version in .NET 4.0.
Here is what I would say after working with the first version for about 6 months using a decent size DB in sql 2k8(40+ tables, several tables with close to 1M rows, and decent amount of traffic)
Lack of Foreign key properties. Meaning if I want to know or work with just the id of a related table I have to load the actual entity. (fixed in next version)
Utter lack of an easy outer join like linq to sql has when using DefaultIfEmpty. Fixed in next version.
Generated Sql is less than optimal This seems to be fixed in next version as well
Very difficult to abstract from your code for testability and for use in multi tiered environments, but it can be done. This can also be classified as the POCO problem that also has been resolved.
There are more, but these are my top ones.
Overall I would use it again, but if you are starting from scratch please save yourself some pain and wait for the latest version or start using the beta if you can.
You might find the walkthroughs for Entity Framework 4.0 useful. All of the new features discussed are annoying emissions from the currently released version for someone.
I found the new TDD/testability features and T4 code generation features especially interesting.
About EF1:
Generated SQL is horrible. It multiples joins, it is 10x bigger than it could. I had a simple query, but with a lot of joins and generating this query by EF (not executing) was slowing down significantly my application. No, I couldn't use precompiled query. I used view to cope with it. SQL Profiler was helpful.
Primary keys in views are not recognized properly. You have to change edmx file by hand when you import view or doing schema refresh.
You can design entities from database in graphical manner, update model from database, but it doesn't always work good, specially when you change field types or foreign keys.
You can't update one table in model, always have to update whole model from db.
You can't define base class for your entities, it is already defined (EntityObject). You can use interfaces, because classes are defined as partial.
No POCO, entity classes are strongly connected to framework.
You can set foreign key by EntityReference.EntityKey, but when you have EntityCollection, prepare for round trip to db. Or am I missing something?
I am finding the POCO objects and model-first design in the EF4 beta very sexy.