Hi Paul,

my data designing is done in xCase: if I want primary contact to show up for a customer, I create a relationship into customer from Contacts: the FK is created by xCase, along with the necessary index. My metadata creates the lookup for me; my framework and builder handle the coding (property setting, actually, no code required). In addition, I can filter the lookup based on whatever criteria I want. If I want to filter on criteria from a table on the other side of Contacts, I create a view on Contacts that includes that which I want to filter on, and specify that to used for the lookup. Now, by the time I get to that last step, I have left the world of ORM as we know it.

But, as you point out, ORM does have that side to it also. What I call the Rails side, how to design simple data structures without having to use a data design tool.

The essential problem addressed by the EF, however, isn't that part (that part is being addressed in VS2010, interestingly), but rather the "how the heck do we work with data without typing the same stuff over and over again in order to hook the data up to objects." The MSDN article points to this motivation. And that issue is one caused by working in a statically typed language.

Hank

>>Hi Cetin,
>>
>>No I'm not kidding: we don't need ORM under whatever name, because we assign a controlsource, and the fields are automatically (dynamically) mapped. In VFP there are not full objects (one can't bindevent a field), but in the extensions created under the VFP Compiler for .Net they are full objects. They could have been in VFP, but development stopped.
>>
>
>I think you're misunderstanding some of the things an ORM will give you. It's not just a strongly-typed interface that you can databind against. A big part of the their benefit is that automatically handle mapping your object model to the data model, which may or may not look anything like one another. Imagine the standard Customer > Invoice relationship. You tell the ORM mapper how they are related and what the object model looks like and it handles the rest (retrieving the data, persisting the changes, etc.). You might have a property on the Customer object called PrimaryContact. In the data PrimaryContact is actually stored in a child table of contacts - that can be transparent to you. That is, the object model can have attributes that don't have a 1-to-1 relationship to the data model.