We've been playing with EF4 for a few days to see if it is a good candidate as a 'data layer' in a project that is being upgraded from VB6. As Kirsten said a couple of days ago, she has some VB6 classes that represent tables and there are stored procs to load and save the classes. She would like to reuse these classes, but I think they're too old and would be a burden in .NET where we expect classes to implement things like IEditableObject, IPropertyNotifyChanged, ISerializable, and have other tracking properties like IsNew, IsModifed, and also know about relationships. I think it would be tedious work to refactor the VB6 classes into modern form when it's so easy to have them spat out more reliably by a code generator.
So we've been reading Programming Entity Framework (2nd edition) <http://www.amazon.com/Programming-Entity-Framework-Julia-Lerman/dp/05965202 8X> by Julia Lerman and running experiments. Now, my first question for you is a bit vague, but please remember that I used classic ADO.NET for the first 5 years, then I used netTiers for the last 4 years to generate a DAL. This is my first serious attempt to evaluate an ORM. Given that, in Julia's book she drags all of the tables she needs onto the EF4 designer surface, tweaks them a little bit with some name changes and says "there's my model". Whoopie! So I ask... * Why is the model nearly identical to the database? All I get is class-per-table with some navigation properties for the relationships. * Why is this superior to what netTiers generates? I see that EF4 can define inheritance and you can make vertical and horizontal slices to redefine pieces of tables, but I can't see where any of this helps us (at the moment). Where is the M in the ORM? What on earth is EF4 doing for me that a boring DAL generator like netTiers isn't doing? I just expected something more 'magical' and sophisticated out of EF4. Perhaps there are long-term benefits of an ORM that we're too naive to see yet. Greg
