EntityFramework withour EDMX

Question

We are about to start using EF as our ORM. We have our own MetaData representing the databse stracture and we will generate whatever we need off of that. We are wondering whether to use the "old" EDMX approace, or to use the new EDMX free approach (wiht DbSet and DbContext). As we do our own code/edmx generation it seems odd to generate an EDMX and then generate objects and context off of it.

The thing is I don't see much talk about about the EDMX free approach. Is it being used by anyone? Can someone with experience share their impressions? Are there known limitations? Are there pros and cons?

Asher

Answer 1

Are you asking if anybody is using code-first? :) By checking the number of questions in entity-framework-4.1 and code-first and ef-code-first I guess people are using it a lot. There were several questions about code-first x non code-first. Some of I answered:

• EF POCO code only VS EF POCO with Entity Data Model
• EF Model First or Code First Approach?
• EF 4.1 Code-first vs Model/Database-first

Generally there are four approaches:

• Model first (database generated from EDMX)
• Database first (EDMX generated from database)
• Code first (database generated from code mapping)
• Database first with code mapping (code mapping manually created for existing database or manually updated mapping generated by EF Power Tools CTP)

Selection of the approach usually depends on the way how you want to develop application (as described in linked answers). It also depends if you want to use ObjectContext API or DbContext API. The former one is usually used with first two approaches (but the secret is it should work with code-first as well) the later one with all of them.

Code first has some limitations - it doesn't support all mapping features EDMX does for example:

• Stored procedures mapping (it doesn't mean you cannot execute SP when using code first)
• SQL functions mapping
• Advanced EDMX features like defining queries, query views, model defined functions
• etc.

What I don't understand is why are you trying to combine your code generation tool with EF. Either use your stuff or use EF's stuff. You will avoid complications and incompatibilities.