Now *that's* the type of feedback we like to get! (We also like to hear about missing features, implementation concerns, etc., but it's nice to know from time to time that some part of what we're doing is on track… )
>I wish you had gone into more detail as to how it works with the database. For example: do i have to create stored procedures that i then map using that map editor thingymebob
While we are planning on supporting stored procedures for C(reate)U(pdate)D(elete) operations, as well as directly invoking stored procedures, these are not required for the mapping.
The "Mapping Provider" we showed, which can be accessed directly using existing ADO.NET provider interfaces, or through ObjectServices/LINQ, uses a "Client-side View" technology, which is based on well understood database view transformations that we perform
on the client machine (hence the name; clever, huh?)
Updates are done in a similar way, borrowing from view maintenance techniques developed by relational stores. The result is a more composable, extensible, and provable mapping solution than the more adhoc "search & replace" techniques employed by typical ORM
We found that, in many cases, it was impractical if not impossible to make changes to relational schemas, including extensions to existing schema or even adding stored procedures/table valued functions. By implementing views on the client, each application
can have their own "view" of the data in the relational store. Of course, this doesn't prevent applications from sharing views, but gives the flexibility to have, and maintain, separate views for different clients.
Note that, although the view unfolding occurs on the client, all of the actual query processing/evaluation occurs in the server, so that the data we get back from the server matches the applications conceptual view of the data.
Okay; probably more than you wanted to know, but we're pretty jazzed about this stuff…