BT

Entity Framework Code-First CTP5

by James Vastbinder on Dec 31, 2010 |

Earlier this month the ADO.NET team released CTP5 of their Entity Framework Code-First library.  The library is meant to provide a code-centric workflow for developers when working with data.  This is the last CTP Microsoft will release before the final release expected in Q1 of 2011.

Entity Framework Code-First CTP5 enables developers:

  • develop without having to open a designer
  • define a model objects by writing classes with no base class required
  • enable database persistence without explicitly configuring anything

Known Issues in CTP5

  • Table and Column Mapping in the Fluent API - quality improvements needed
  • Pluggable Conventions - early preview in CTP5, more testing needed
  • Validation Feature - only supported when using Code First

New Additions since CTP4

DbContext

  • T4 Templates for using DbContext/DbSet
  • Validation of objects on save
  • Change Tracker API
  • DbSet.Local exposes an ObservableCollection representing the local contents of the DbSet
  • Support for No-Tracking Queries via the AsNoTracking extension method on iQueryable<T>
  • DbContext Configuration
  • Raw SQL Query/Command
  • Improved Concurrency conflict resolution

Code First

  • Full data annotation support
  • Fluent API Improvements
    • Simplified table and column mapping
    • Ability to ignore classes and properties
  • Pluggable Conventions - an early release, work still yet to be done

Changes from CTP4

  • New Assembly Name - EntityFramework.dll
  • Better Code-First to existing database support
  • DbContext.ObjectContext has moved - get context via ((IObjectContextAdapter)myContext).ObjectContext
  • Excluding EdmMetadata Table
  • Class Changes
    • System.Data.Entity.Database.DbDatabase
    • System.Data.Entity.Database.DropCreateDatabaselfModelChanges
    • System.Data.Entity.Database.DropCreateDatabaseAlways
    • System.Data.Entity.Database.CreateDatabaselfNotExists
    • System.Data.Entity.Database.SqlConnectionFactory
    • System.Data.Entity.Database.SqlCeConnectionFactory

Developers like the ease of installing the library with NuGet in Visual Studio and the fact it can be used against data living in SQL Azure.  Since the release, Morteza Manavi has put together an excellent series of articles on inheritance mapping and entity association using CTP5.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Is this worth Microsoft's time? by Francois Ward

This is really neat, but I wonder if serious developers really are interested in it. I've always wondered what was the niche for code first ORMs. There are a few out there, and I know people using them, but they are few and far in between, and usually it causes more problems than it solves.

My logic here is that:

If you want a solid, testable, well architected, controlled application, the database first + POCO model of the entity framework is one of the better ones out there, even when compared to NHibernate (being able to easily mock the Context and thus easily test your repository and LINQ queries without needing an in memory database is just -awesome-).

If you need fast development, RAD, or you're a small shop who just wants to get things done, database first + design surface (or a third party designer, namely LLBLGEN, kind of a necessity for large databases) will get you to your goal asap.

Code first seems like it forces you to code almost as much as POCO, while making you spend more time thinking database (because everytime you make a class, you have to remember the conventions, what it will do to the database, etc. You can't just do it blindly), you have a super tight coupling between code and database... you don't get all the advantages of POCO, and you're slower than database first + designer.

Where's the gain exactly? The obvious answer would be for people who don't want to think database, and just create their model in code then having the DB generated for them, but in practice that doesn't work really well.

Re: Is this worth Microsoft's time? by Mark N

I agree with your title, but not what you actually mean. I mean really, why build all this when there are things like NHibernate exist that they could just support or build a commercial version.


I've always wondered what was the niche for code first ORMs
Everyone who wants to do OOP and not just layer object structures on a RDBMS.

To answer your question: Yes, PLENTY of people do "code first". It is called domain driven design. Doing the database first is so ... well not 2000+. The database is not the center of the universe anymore. Sure, sometimes it makes sense to not create domain objects and use an OR/M. But if you are building a "business" application, i highly doubt it.

I can most definitely build my objects first and create the database second much faster than the other way around. For instance, see Spring Roo. Even without it, i still can.

Code first seems like it forces you to code almost as much as POCO, while making you spend more time thinking database
It doesn't.
you have a super tight coupling between code and database
No you don't. Typically, database first has this issue. I have seen it plenty of times.

With Domain first, I can create the domain, repository and service without a database. I can switch rdbms vendors. I can switch database types. I can have subclasses with table per class, table per subclass, and joined table.


The obvious answer would be for people who don't want to think database, and just create their model in code then having the DB generated for them, but in practice that doesn't work really well.
Oddly enough it works VERY well. Maybe you need more practice.

Re: Is this worth Microsoft's time? by Francois Ward

With all due respect, i think you're confusing Model first with Code first. Domain driven design doesn't start with code, it starts with your domain. It just so happens it isn't uncommon to have a 1:1 relationship between your domain model and your code (for obvious reasons).

Entity framework supports Model first already. You don't need this CTP for that. You can make your model, and get the code AND database generated from it, or use the POCO model with it. Thats not an issue at all.

This CTP is for code first: you jump straight in Visual Studio without necessarily having a model, using very specific conventions, and it does some guess work to generate your model and database from it. Sure, you can go with the class designer, make sure you follow the conventions, and go from there, but thats the same thing as Model-first, but worse.

So i reiterate my question, as it maybe wasn't clear: whats the point of the code first model, as opposed to database first or model first (either using the entity framework modeling tool, or creating your domain model in a third party tool, getting your database from that, and then using the database first entity framework workflow)

Re: Is this worth Microsoft's time? by Russell East

I sort of agree with Mark. From my point of view, code first is Microsoft's version of Fluent NHibernate. Which is very common and is a lot better that working with XML mapping files. So actually I think MS is supportting developers that are used to developing in a domain driven manner that may have typically been from the NHibernate camp. I personally have used NH for years and used Fluent NH. EF4 has certainly becoming a threat to NH by bringing out this CTP. (providing that it supports enums now).

To justify this approach, I am TDD through and through and if i have to change an domain object and add a property, its easy to change the mapping class in code and ensure it works via tests. I like my hands on the keyboard and using the designer slows me down.

Re: Is this worth Microsoft's time? by Francois Ward

@Russel

Actually, Code first is completely different from Fluent NHibernate. Fluent NHibernate is Database first, with C# for the mapping instead of XML. If you use Fluent NHibernate and use the SchemaExport Nhibernate API to generate your database, you're using a "Model first" approach, where your model uses a C# notation instead of a design surface (its not generating your database from your classes, its generating from your mapping, which is explicitly defined and doesn't have a 1:1 relation with your objects)

Entity framework code first is not the same as model first at all. You create your classes with no mapping (no model), and using conventions it creates your database. That is what I find to be very niche. Very few ORMs use this approach, and the ones that do have very small market shares. On .NET, one that comes to mind is XPO by devexpress. SubSonic has multiple models and one of them work that way (though its very limited).

Re: Is this worth Microsoft's time? by Russell East

@Francois.

Are you saying that you Model is your mappings? My Model is my domain model which is represented by my classes.

I wouldn't say they are completely different technologies. EF is can use convention over configuration where Fluent NHibernate can use Automapping. Personally, I like to be explicit customise the mapping so i can set up unqiue properties, nullables etc. EF can do this with by overriding the OnModelCreating and use the ModelBuilder. In both cases i don't do database first and use the SchemaExport tool which NH, but both technologies use existing databases which i would expect from an ORM.

Its not niche, most of the developers I have worked with our the last couple of years would use this approach. I know of whole teams that develop this way. Clearly if you don't provide mappings and let EF generate the schema that you are using an "Active Record" pattern. Which is common approach as well but less flexible. So "Is this worth Microsoft's Time?" yes.

Re: Is this worth Microsoft's time? by Francois Ward

@Russel

No. I'm saying YOUR model is your mappings, not mine :) If you generate your database using SchemaExport, what do you think is used as the model definition?

As for Active Record, that pattern simply means the classes know how to persist themselves, as opposed to a "service" model (is there a better word?) where some kind of unit of work manager handles it and the classes are "dumb". ActiveRecord just happens to be the most common one used in "RAD" tools that will take care of your DB for you. (I think RoR does it? Never used it)

I think the confusing however, comes from the fact both you and Mark think i'm advocating database first. Keep in mind that Entity framework can do: Database base first with autogenerated model (with autogenerated classes or POCO), database first with manually created model (with autogenerated classes or POCO), Model first with autogenerated DB(with autogenerated classes or POCO). Model first with manually generated DB or database first with manually generated model is the same thing. This CTP is code first, with no physical model (deffered by conventions).

So what you're doing with SchemaExport and NH, in EF equivalent, is Model first with autogenerated classes. You don't need this CTP to do that.

My question was, in which situation are you saving time or working better by creating your classes, very carefully crafting them to follow an unnatural conventions, simply so you don't need to take the 3 minutes to draw your model on the design surface.

The one case I can think of, from watching people use XPO or SubSonic, is when you have a very small amount of tables, no foreign keys, and a very "dumbed down" database (because code first tool that let you create complex schemas quickly make your classes very complex, with very weird conventions and/or attributes everywhere). THAT is what I feel is very niche: Microsoft spending a lot of time to do something that is very complex technically, only to save 3 minutes for the most simple scenarios.

What I am NOT asking is why would someone use their app to create their database. I do that frequently too. Not for all my apps, but sometimes creating my DB from my model is a blessing to get started quickly. No arguments there.

Re: Is this worth Microsoft's time? by Olmo del Corral

@Francois

Hi Francois. I'm the one in charge of Signum Framework (www.signumframework.com/) maybe the most code-first framework out there.

We released it almost 2 years ago and we have a limited success. We will try again this month with 2.0 version, let's see.

I totally agree with u that, if you want to keep your schema, writing the entities by hand is losing time. It only makes sense if u take some radical decisions.

Our framework is more code-first than anyone else because, in order to make it more productive, we take decisions that makes us unable to work with legacy databases, instead we need complete control from the schema.

We also don't allow POCO, your entities have to inherit from some base entities that also force some fields in the database (Id and ToStr).

These radicals decisions are the reasons of our limited success, and also the reason of being so productive:

* Thanks to snippets and succinct code, creating the entities is as fast, if not faster, than creating the tables in the schema.
* Because you have control of the entities u can add validation on there easily.
* There's just no mapping at all, no XML, no Fluent, no Conventions. Theoretic you can change the names of the tables and so, but we never do it.
* The database is generated automatically, and when u makes changes in the schema a sync script is made for you (you have to review and execute).
* Thanks to the homogeneity of the entities we can give wonderful default behaviors to the controls in the user interface:
- Validation works by itself
- Navigation between entities is automatic
- Combo boxes get filled automatically (for enums and non-enums)
- Auto complete works by itself
- We can make powerful search (complex filtering, ordering and even adding and removing columns) just by writing a LINQ query.

* Also we improve dramatically the composability of the application. We can easily build vertical modules (Database-Entities-Logic-Win/Web user interface) that get integrated seamlessly in an application in 2 lines of code (one to register in the database, another one in the user interface).

* Having control of the entities and having a homogeneous validation also simplify creating automatic documentation (MSDN like) that you can also integrate into your application as contextual help.

* It also simplifies creating a Authorization system that allows permissions to any resource (entities, properties, queries, ...).


To put it clear, having control of the entities, together with inheriting from carefully designed base classes, allows a level of reutilization similar to what 'everything is an object' bring in the old days where Java arrived. Before this everything was more manual.

In my opinion, trying to write POCO classes, repositories, etc... to make your application more 'ORM independent' is a mistake almost as big (but much more frequent) as trying to make an application that works at the same time in .Net and Java.

Re: Is this worth Microsoft's time? by Dandik M

@Francois As Russell mentioned, but did not explain, Fluent NHibernate can use Automapping to generate database without any mapping model in xml or code. Code first no?

As to: Is this worth Microsoft's time?

Ask your self how often companies change technologies that they use? Like how often you will be willing to change ORM after 5 projects that you need to maintain and 3 projects going on? So it is a decision that is carefully considered. But what can you say about what you'll need for future projects, that you do not know of yet? Not much really. Are they going to be small or big? Etc.

At the end you get the list of features the ORM support and compare ... so:

NHibernate supports:

1) Database base first with autogenerated model (with autogenerated classes or POCO)
2) Database first with manually created model (with autogenerated classes or POCO)
3) Model first with autogenerated DB(with autogenerated classes or POCO).
4) Model first with manually generated DB or database first with manually generated model is the same thing.
5) Code first, with no physical model

Entity Framework:

1) Database base first with autogenerated model (with autogenerated classes or POCO)
2) Database first with manually created model (with autogenerated classes or POCO)
3) Model first with autogenerated DB(with autogenerated classes or POCO).
4) Model first with manually generated DB or database first with manually generated model is the same thing.

5) Code first, with no physical model - NO

hmmm what if we'll need code first for some reason? Lets take NHibernate just in case.

The less mature the company, the more obvious this is. And as this decision needs to be made from day 1 ... well many companies will not that mature at day 1, so ... just compare the features!

Is this worth Microsoft's time?

From tech people point of view - probably not
From sales point of view - most obviously YES!

Re: Is this worth Microsoft's time? by William Wixon

@Francois most people at my company prefer code first. It allows us to worry about our domain without even thinking about storage. Model first makes you create what are essentially DTOs to work with the ORM. When I was using NHibernate I had plenty of object graphs that worked easily with the ORM, no need for extra objects to maintain. We have had other problems with NHibernate that is making us review Entity Framework but without Code First we will not consider it seriously. I don't want a DTO object for every domain entity I make.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT