First of all, fascinating project.
I do have a question though. Currently in VS 2008 Beta 2 there is a new item which is LINQ to SQL which creates a couple files including a mapping to the database which can be queried using LINQ. You also get a design surface that looks similar to the Entities Design Surface.
What are the differences between the two (ie, why do they both exist) and why would one use one or the other?
Excellent question. It seems like MS has been trying to give us an O/R Mapping type product/services since the Object Spaces annoucment. Since then it has been false start after false start. I remember that Italian guy doing a C9 demo on Object Spaces years ago... where did he go?
Now, it seems like you have two competing technologies that actually might ship. I see alot of overlap between the two and also each has some features the other doesn't have.
Do these two teams know about each other? Why not merge the projects and come up with a single, consistent set of libraries to solve the problem of moving data from relational to object model.
Also, is there an Object first design paradim that you can do. I understand why all of these demos reverse engineer a db... but, can I create an object model first and then have in create my schema for me?
The LINQ to SQL objects also have partial method hooks that allow you to add business rules/validations to them. Is there anything like that in the Entities? Are the entities designed to also be the DTO's or are the entities just a way to tell link how to shape the objects that are returned from queries.
I think The main difference between the Entity Framework and Linq To SQL is that EF provides an extra layer of abstraction over your data model, whereas in LINQ to SQL you code more directly against the DB schema. This allows for a much more robust entity model that is not not as tightly coupled - giving you the freedom to change your actual DB schema without affecting your business logic. You can redesign your "store" to maximize performance / normalization without breaking code.
I'm not sure, but i think if you take an inheritance hierarchy from your data model - say Person -> Customer - and see how it is translated by each technology, you will see a difference. I think the EF would allow you to access all the person properties directly in your customer class (like an inherited class should be) but in Linq to SQL you would access the person interface using Customer.Person...
It is my understanding that the "Object Services" feature of EF creates partial classes which allows you to create your own partials to do all of your other work - non persistent properties, methods, authorization, validation, etc.