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.
I've been following this project for a while and I'm very excited. It's almost like the "missing link" to really getting apps up and running more quickly.
One thing I am concerned about though is the fact that very often Entity Diagrams can get really complicated and crowded. Most ER Diagramming tools allow you to have multiple pages, or multiple sub-diagrams to help you organize your entity model. I haven't
tried the product yet but I am hoping that the visual tool allows for such a thing - multiple pages / sub-diagrams.
Very cool. I always really enjoy Pablo and the things he demos. His enthusiasm is infectious. This looks great, but I'd much rather have him pushing Entity Framework out the door than focusing on the next thing.
If i understand this correctly...it will allow you to write something like this:
(this assumes you a have a person, and a form1 with a textbox)
In other words you can incorporate runtime results back into sourcecode - effectively eliminating the need for things like a select case block(in certain situations). Of course you would have to validate, or limit the value of, the textbox.text to insure the
existence of that member in the calling type.