I thought I'd just have my say about this as these gentlemen already have [ PeeWeeWilson & Fouma ]. After having read the overview paper (rather diagonal I might add) I can't help but notice the three-way mapping is gone (domain schema <-> mapping schema <-> relational schema), which I find a pitty. From the simplicity point of view I can fully understand why, but believe me when I say that flexibility is sacrificed.
Recently Steve Eichert mentioned using DataContract as a way to describe what is persistable and what is not. An interesting idea, but there are too many references to the web service world (Namespace, MustUnderstand, ...). Secondly, if I'd like to expose the class/message using [DataContract] via a web service I wouldn't feel very comfortable with "what is persistable" and "what is part of the message" being the same. Creating a new set of attributes [PersistenceContract], [PersistenceMember(Name=...)] and [PersistenceMemberReference(Name=...)], [PersistenceConstructor] sounds more appealing to me. They could form the domain/persistence schema, which could in turn be consumed by the mapping schema or code which defines the mapping/transformation.
Unlike Paul and Frans, I don't advocate against using attributes. What I do advocate against is the fact that relational concepts such as table, column, native or abstract column types, primary or foreign key and relationship show up in my domain model, and this for the very same reasons as Paul & Frans do (call it one thing in SqlServer, call it another in Oracle; inject some kind of custom transformation in the mapping because there is a mismatch between the CLR type and the native db type). Unfortunately this is exactly what DLinq does. Marketing-wise this could be interpreted as "Let's sell more SQL servers". Opening things up would only allow you to switch to Oracle more easily. Wether that was the reasoning behind this all, I really don't know. Let's just hope that in the future DLinq will embrace flexibility and database independence. Resources on Linq
|