Persistent problems

It has been a relatively difficult week to get into, work-wise. There's a lot of patchy development going on, but much of it has been client or software dependent, so I've spent most of the time dealing with some problem or other. Problems are not like buses. There is normally one at your door every day. Unfortunately, most of them arrive at most inconvenient times - usually when you have the least amount of time to address it. This week, that hasn't been too much of an issue. I've managed to sort quite a few issues for good, although I fully expect that comment to come back and bite me on the bottom rather harshly.

One of the most difficult things for me personally is reconciling my natural nature ( talkative and social ) with the established discipline of a programmer ( solitary and focused ). As a consequence, it's nice to have a bit of time to solve issues thoroughly and then get to tell people that'll most appreciate it that you have improved their day.

The other theme of the week has been persistence. We're currently looking to develop a .NET 2.0 version of our existing software platform. As part of the initial analytical steps, I've been looking at other Object Persistence Frameworks with a view to cribbing good features or if one is good enough, adopting it entirely.

It would seem that most people are having the same issues with making the generational leap that we are currently facing. Many of the object persistence frameworks I have looked at have not yet made the leap to .NET 2.0 either, rendering them entirely unsuitable for adoption. I've also been surprised at the large number of object persistence frameworks that employ XML mappers to tell the .NET layer about an underlying data object. With a series of self-describing databases implementing the SQL 92 standard in some fashion or another, it amazes me that more people have not made use of readily available and completely up-to-date schema and relationship information that these databases have to offer. Why bother creating the additional overhead of creating and maintaining an XML mapper when the database can give you a real-time account of what's what? A schema change invariably means a mapping change, and even then, you're still missing a lot of that referential information that a self-describing database can provide.

I came away from my investigations with the distinct impression that even though our .NET 1.1 Platform is not without its flaws, it is still head and shoulders above a lot of the stuff out there. Better still, we know how it works, and are not at the mercy of developers when we discover bugs.

Still, there are a couple of frameworks that have definitely caught my eye. DomainObjects looks extremely promising, whilst I've admired the tenets of the Gentle .NET framework from afar for a long time, a natural candidate for adoption if a .NET 2.0 version was available. We've got a certain timeframe in which to accomplish some pretty big strategic stuff. My general feeling at the moment is that it would take as much time to evaluate all of these frameworks as it would to get a couple of prototypes up showcasing our own approaches to the problem.

It'd be great to be able to bring one of these babies in and spend more time playing around with the Business Objects, but I'm increasingly of the opinion that if you want something doing properly, i.e. in the way that best suits your own circumstances, you're best off doing it yourself.