Steve Eichert posed an interesting question regarding O/R mappers and the use (or lack thereof) of attributes to define the details of mapping business entities to relational database tables. He specifically asked why attributes are good enough for Indigo, but not for O/R mappers? Paul Wilson, the creator of WilsonORMapper (which I think is currently one of the best mappers in the .NET world) replied with a couple of points describing why he prefers to use XML:
- Persistence is external to my entity objects — I can and do use my entities differently at times.
- Makes it easier to change the O/R Mapper I use — not totally seamless, but easier if pure POCO.
- Table and field names can and do vary at times — customers of my apps do have different schemas.
- Makes it easier to reuse my entity objects — the same business logic can be used in different ways.
- Personal preference — focus on business only — I just don’t see the point of attribute clutter.
While I’m certainly not opposed to either approach, and think that each has its merits, I believe that the benefits of an attribute-based approach are somewhat under-represented. I also think they are misrepresented in several ways as well. I’ll offer up this point by point breakdown:
“Persistence is external to my entity objects — I can and do use my entities differently at times.”
Persistence is indeed external to the inner workings of a business object. However, attributes are metadata, and do not define any behaviour. Marking a business object as [Serializable()] is exactly the same. The fact that it can be serialized has nothing to do with the business object. You’re just marking it for some other process, in case this information might be useful elsewhere. There is no difference.
“Makes it easier to change the O/R Mapper I use — not totally seamless, but easier if pure POCO.”
I’m willing to tag this argument as YAGNI. Using XML because you might switch out an O/R mapper for another is stretching things somewhat.
“Table and field names can and do vary at times — customers of my apps do have different schemas.”
This can easily be done using attributes as well. [TableColumn("databaseColumnName")] does this nicely.
“Makes it easier to reuse my entity objects — the same business logic can be used in different ways.”
Once again, attributes are just metadata. They should have absolutely no bearing on how an object is actually used. Unless you’re doing something completely wacky with your attributes (like basing business functionality on them), this argument doesn’t hold water.
“Personal preference — focus on business only — I just don’t see the point of attribute clutter.”
Point granted. Attributes can clutter up a class file to some degree. But the flip side of this, is that it’s easy to see anything related to your object at a glance if you use attributes, by going to the source file. Everything you need is right there, in one place, not spread out over multiple files. This is an often overlooked point in my mind.
So there you have it. In my mind, it really does just boil down to personal preference (or the preference of the dude writing the O/R mapper). Do you want all your information in one place where it’s easily accessible, or spread out over multiple files to keep things nice and tidy? Take your pick.
So my buddy Buckles was apparently frustrated with his blog at some point (just look at the title in the upper right). Apparently he forgot to change the title, and then left for a two week vacation. Now he’s on page two of a Google search for “Shit Paste”. Unintended consequences are sweet.
Have you ever thought to yourself “Hmmm… What I need here is an uber class that does database access, file access, logging, e-mailing, Amazon/Google searching, and xml processing”?
More importantly, would you take lessons from a person who wrote one?
Enter… The Utility Belt
Go ahead! Copy ‘n’ paste it and use it right away (actually, it takes about 1 minute to highlight all the code without using ctl-a). It’s 6116 lines of kitchen sink goodness for yer lernin’ pleasure.
My current employer is looking for a developer with solid C#/VB.NET, ASP.NET, and Microsoft Content Management Server skills. The position is located in Calgary, Alberta, Canada; you must live in Calgary (or be willing to re-locate) to be considered for the position.
Pangaea’s a solid company to work for, and has a close relationship to Microsoft. If you love playing with the latest Microsoft technologies, it’s the place to be in Calgary. You’ll get a highly competetive salary, full benefits (immediately, not after 3 months), a private work space with walls you can write on, the list goes on and on. If you have any additional questions, don’t hesitate to e-mail me.
I found MonoRail after following a link buried in the comments of Zac Bowling’s Hot or Not post from a couple of days ago. Now I’m wondering how I managed to go so long without hearing about it before…
Obligatory what the heck is he talking about quote from the Castle website:
MonoRail (former Castle on Rails) is an attempt to provide a port of Action Pack for .Net. The Action Pack way of development is extremelly productive, very intuitive and easily testable.
There’s also a few Flash Demos you can watch. Definitely worth trying out.
I worked with Ted O’Grady for a very brief period of time on the Inform Alberta website over a year ago. It was the first Agile project I’d ever encountered “in the wild”, and what Ted was doing with the project was fascinating to me. Imagine my surprise when I stumbled across his personal site today, and found out he has a blog.
Not only does he have a blog, but it’s a darn good one. I really like the short, concise writing style, and appreciate that he mananges to put something helpful or meaningful into every post. Go read. Now.
This paper by Jim Highsmith (Wow. I almost camel-cased his last name. I think I need a few days off…) provides a pretty diplomatic rebuttal to a few common objections people have with Agile Processes. The Cole’s Notes version:
- Most objections are based on misconceptions of Agile processes.
- People confuse XP with Agile. XP is one form of Agile development.
Via Clarke Ching
I just found this post by Darrel Norton:
Keeping NUnit config files in sync
It details how to go about setting up a post-build event to copy an App.config file to the proper directory (while renaming it) so that your test assembly can get configuration information. I struggled with this for a few minutes today.
I finally decided to take a look at Ruby on Rails yesterday. It looks incredibly slick, with most of the benefits appearing to stem from the dynamic nature of Ruby itself, as well as a focus by the developer(s) on simplicity. Compare a Ruby on Rails beginner tutorial with it’s Java/Spring equivalent:
Ruby on Rails
All I can say is.. Wow. You be the judge. (Keep in mind that Spring is a lightweight java framework)
Via Jeff Atwood, go check out the Managing Product Development blog. In particular, the Schedule Games series of posts is interesting. Consider me subscribed (my first new subscription in over 2 weeks!).