No Long Days

I just finished watching the "Entity Framework Futures" PDC2008 session recording.

What I got out of it is a few things. First, they are really listening to feedback and taking it to heart. Where previously they were saying "You just don't get the vision of the EDM"... now they are saying, oh yea, if you only want to do OR/M and use model first, BDD, TDD having POCO (plain old clr objects) really makes the experience easy.

So, here are some things they showed that I really liked.

1. POCO support.
2. Code based mappings.
3. Support for lazy loading opt-in.
4. Generate Db from the model.
5. Convention over configuration.

It seems that the POCO changes will make this product a world better, even for the nonAgile crowd. Having all those decorators, and attributes, base classes and partial classes and methods really pollutes your domain classes and makes your code smell.

What I didn't like.

1. The db generation from model is destructive. (is that all?)

Oh... yea that's the main thing. What I don't understand is why. Visual Studio for Database Developers (Data Dude) has already solved this problem. Data Dude keeps a model of the database in metadata. The data dude designer lets you modify the db model and then push it out to the database in a NON-Destructive way.

I would like to see EF work with the data dude model. Update Database from Model could leverage the data dude model and non-destructive update. This seems like a no-brainer to me. It seems some of these MS tools are such islands and they try to solve the same problem multiple times rather than working together.

Another example of not working together is that EF designer doesn't leverage the DSL tools in Studio. WTF? Using the class designer as the base to design your conceptual model seems to make so much sense to me. It is already two-way so you can edit code or classes. They then could have used the Data Dude physical model to store that metadata. This means they would only need to store the mapping metadata.

Yes yes, I know, the EDM is a "platform". Sure, but isn't Visual Studio a platform too? Even with EF v2 it looks like I will have a total separation between my (whitehorse) class diagrams/code and the Entity Model designer. This just makes no sense to me.

To summarize, I really like what they are doing with V2. I'm just wondering why this wasn't the path they took with V1. It really goes to show how being transparent with design ideas up front is really an advantage. When they showed EF originally the first thing most people said was, why does it not support POCO? Of course, at that time it was much to late to shift gears.

That all said, I am still moving forward with my architecture design using EF, Astoria, and Silverlight 2 for our next major version. While I would like to have POCO at this time, NHibernate is just not an option. Using out-of-the-box supported and documented products has a much higher value proposition. Dev's of the street are more likely to have experience with in-the-box technologies. Also, the visual designers of ER are much more productive than the hand mapping needed with NHibernate. (Yes, I know there are some alternatives, but none are fully baked.)