Yves Reynhout's Blog
The seagile man
September 2005 - Posts
DLinq - First Impression
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
More Posts
Search
Go
This Blog
Home
About
Tags
.NET
Code generation
Corporate
Mediator
MVVM
NAuthorize
Object/Relational Mapping
Silverlight
SOA
WPF
Navigation
Home
Blogs
Archives
October 2009 (1)
September 2005 (1)
June 2005 (1)
May 2005 (1)
April 2005 (5)
October 2004 (1)
June 2004 (3)
March 2004 (2)
February 2004 (1)
January 2004 (1)
December 2003 (1)
November 2003 (1)
October 2003 (8)
July 2003 (1)
May 2003 (1)
April 2003 (2)
March 2003 (3)
February 2003 (5)
NAuthorize
NAuthorize on forge.novell.com
Sun's XACML implementation
XACML @ OASIS
RBAC @ NIST
Ravi S. Sandhu
RAD by Healthcare DTF @ OMG
Testdriven.net
Syndication
RSS
Atom
Comments RSS