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.