If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

posted Sunday, June 19, 2005 11:03 AM

I’ve recently been reviewing the code for my Entity Framework (simple O/R Mapping, Entity validation, etc) to determine if I should consider swapping out the O/R Mapping for something else such as NHibernate, NPersist, Wilson OR Mapper, etc.  The reason I’ve been considering this is that swapping out the O/R Mapping functionality within my Entity Framework with one of the more widely used frameworks may make it easier for people to extend ActiveType (CMS) for their unique needs.

As part of my review I was investigating the differences in functionality between the other O/R Mappers out there and the lightweight O/R mapper I’ve developed in my base Entity Framework.  There are a lot of obvious differences, but, as you might be able to tell from the title of this post I’m going to focus on how the mapping is configured in the various O/R Mappers.  Most O/R Mapping products out there today have the mapping of objects to database tables defined in an external configuration file.  There are some (mine included) that define the mapping within the classes themselves via custom attributes. 

I’ve recently been reading up on Indigo and as I’ve worked through all the code samples I couldn’t help but notice their extensive use of attributes.  Although O/R Mapping and Indigo are clearly not one in the same I can’t help but notice the obvious similarities.  I can’t help but think there are others that agree:

One last point, [DataContract] is just not an "Indigo" feature -- it is a feature for the entire .Net Framework.

Thinking about it in only Web services terms doesn't do justice to the host of important scenarios that it addresses elsewhere (version-tolerate persistence for any CLR type in any store).

We are defining a common abstract data model for CLR types for N scenarios -- many of which are Web service related.

http://www.douglasp.com/PermaLink.aspx?guid=01095547-b7f1-4e1d-8c4e-31038296f164

If [DataContract] is not just an Indigo feature but a feature for the entire .NET Framework then why couldn’t it become the center point for an O/R Mapping engine?  And if attributes are good enough for defining [ServiceContract], [OperationContract], and [DataContract] why couldn't it also be good enough for defining details to be used by a persistence engine?

9 Comments

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Sunday, June 19, 2005 2:17 PM by Paul Wilson    
I prefer xml mappings because:

1) Persistence is external to my entity objects -- I can and do use my entities differently at times.
2) Makes it easier to change the O/R Mapper I use -- not totally seamless, but easier if pure POCO.
3) Table and field names can and do vary at times -- customers of my apps do have different schemas.
4) Makes it easier to reuse my entity objects -- the same business logic can be used in different ways.
5) Personal preference -- focus on business only -- I just don't see the point of attribute clutter.

How is Indigo different then?

1) The service class typically requires a service.
2) There are not usually multiple service brokers.
3) There is not often a need for multiple versions.
4) The service itself is the means of reuse here.
5) Personal preference -- focus is the service.

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Monday, June 20, 2005 5:29 AM by Alex James    
I have to say I kind of agree with Paul on this one. XML mappings make sense for O/R mappers. Since mappings can change independantly of the rest of the business object. Surely that is the whole point of an O/R mapper?

However in my 'Ideal' world there is something else that encapsulates the mapping for me. For example a Server? So that my client code can use those objects without needing to load a mapping file.

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Monday, June 20, 2005 12:57 PM by Steve    
Yeah, I agree with Paul as well, but I also wonder if there may be reasons that the Indigo team chose to go with an attribute based approach as opposed to a xml configuration approach. I suppose some of Paul's points regarding the differences explains some reasons. I'll need to dig into Indigo more before I can make my own conclusions. Thanks for the thoughts...

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Monday, June 20, 2005 4:42 PM by Alex James    
Steve,

I may be missing something because I've only had a cursory look but I think [DataContract] and [DataMember] are 'what' not 'how'. I.e. It tells us what we need to do, i.e. we need to persist the object and the fields marked with [DataMember] too, it doesn't tell us How. That seems different from O/R Mapping files which are about How. What do you think?

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Monday, June 20, 2005 11:40 PM by Steve    
Alex,
I'm still tring to figure out what exactly [DataContact] and [DataMember] are used for :) My impression from reading over some docs was that they're used to define the "schema" that is shared amount the services ([ServiceContract] & [OperationContract]). I was trying to create a Indigo project on my local machine to have a look at how one might use DataContract and DataMember but I wasn't having any luck. I'll look to try again and report back on what I think.

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Wednesday, June 22, 2005 10:10 PM by Joe    
The OR Mapper I use supports both XML Mappings and Attributes...essentially abstracted which are used. Attributes are good for RAD ... BUT I have noticed that sometimes, particularly when re-use is desired, that you need 'contextual' attributes. By separating how I've implemented the attributes (ie via XML or directly), I can do this.

My current concern for Indigo is that my data contract may in fact be contextual and I'm loathe to implement more than one object.

Perhaps this is more a concern for libraries/re-usable data libraries.

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Thursday, July 07, 2005 1:08 AM by Jeff Perrin    
I started to reply, but it got too big, so it's now a full-fledged post:

http://blog.jeffperrin.com/testosteles/posts/444.aspx

# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Sunday, July 10, 2005 8:58 PM by hammett    
Definitely attributes.

ActiveRecord adds attributes sugar and performs the integration with NHibernate - for me its the best of both worlds.

http://www.castleproject.org/index.php/ActiveRecord


# re: If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers?

Monday, April 07, 2008 7:16 PM by Tony    
Jeff Perrin's post is now at: http://www.jeffperrin.com/index.php/2005/07/

Post a Comment

 
 
Prove you're not a spammer: 
1 + 2 =