After some though I came up with an idea on a multi-part article that I think will be useful. It will cover one aspect of programming I am currently struggling with at work - namely persistence.

I believe, as Ayende puts it, that the persistence problem has been solved. On my personal projects I use NHibernate with some very good success. It's been hard-fought and I'm the first to admit there is quite the learning curve to it. But in the long run it's worth it.

At work, on the other hand, we use table gateways and we end up with reams of transaction scripts spread throughout the application. It is procedural programming disguised as objects, and the issues associated with it are numerous and a constant source of pain and suffering - at least for me. Code duplication is rampant, business logic is frequently implemented in stored procedures - which subsequently become un-usable in other areas of the application. A fair amount of logic is spread trough the code behind of pages and sometimes as orphan classes in the App_data folder of all places.

I've spoken to a couple of colleagues about NHibernate and OR\M in general but there seems to be a disconnect somewhere. I suspect the issue is with a lack of understanding of the basic OR\M patterns that enable a rich domain model and encapsulate the complexities of persistence.

This mini-series will be about basic OR\M patterns, and it's intended to provide a side by side comparison of the options available to us - from hand rolled to meta data driven. I will try to demonstrate - with code, not just talk - the advantages and disadvantages of different patterns, hopefully evolving from one to the next organically, as the requirements become more complex. I have a feeling I'm under estimating this in more ways than one, but we'll see where it goes.

As always feedback is always welcome.

It's been a while since I started this blog, and it's been a while since I've updated it with anything meaningful (if ever). Lots happened and I got caught up in the daily grind. We've had our second kid and that certainly doesn't help with free time to post on the blog.

When I first started this blog I had some goals in mind. I've accomplished none. I am not very articulate in English (it is not my native language as you might have noticed) so I was hoping to improve on that. I was also hoping to share some of my ideas and experiences with you, the reader, since it is somewhat rare that I get to enjoy a free exchange of ideas; you know, talking to somebody who's ego is not larger that the known universe, and who knows what a bloody decorator is. That didn't work out at all, and it's probably due to the poor content I've offered so far. I will try to do better.

It's somewhat difficult to decide what content is worth writing about because every other topic has been covered pretty well and in depth on a myriad other blogs. Also I find myself dealing with a lot of procedural code lately and who would be interested in that? In fact come to think of it, it is the pinnacle of procedural code, so there may be some value dissecting that. Along with the long list of antipatterns i've been exposed to lately - mostly the mushroom management comes to mind.

More to come!

I think there's a gremlin messing with my code. Code is shifting under me, moving around, unit tests are considered  the work of the devil and keep disappearing from source control. Check-in logs refer to my code as crap, and code seems to be refunctoring itself. I don't think it could be a colleague, surely it must be a mythical creature, a gremlin. This gremlin is a fan of singletons and static metods, and thrives on repeating every piece of logic in at least three places. Unit test appear to be its greatest enemy, and they disappear without trace almost as soon as they are checked in. How do you stop such magical creature? What magic power do I need to make this gremlin go away?

Did anybody else encounter this creature, somebody who can offer some advice as to how to go about banishing this destruction from my code base?