Archive for June 2006
I’ve run into a lot of posts and discussions about object-relational mapping over the last few weeks. The most comprehensive of these is Ted Neward’s post in which he expands on the comparison between ORM and the Vietnam War. He has also posted a followup here. Very interesting and thought provoking. Through these posts, I found the link to db4o. I’ve never come across this project before (maybe I’ve been looking in the wrong places.) My initial impressions are good. I had it installed and working in next to no time. I expanded on the tutorial a little and that worked like a dream. I have a lot of questions that I’m hoping a little more time and experimentation will answer, but it’s definitely worth a look.
As Marc has noted, the combination of good weather and the World Cup is great – but has reduced the time available for blogging and nspectre. The good news on the nspectre front is that I am continuing to make progress with logging. There is now logging (and testing of the logging) in most of the classes that I wanted to include in the next release. The Generator now logs generated code (if the Level is set to Debug) – which should help with debugging template issues. With a bit of luck, a fair wind and, maybe, a spot or two of rain there should be a 0.8 release sometime next month.
Between World Cup matches, I stumbled across news of the Dell XPS M2010. It's a sort of desktop / laptop hybrid with a 20" widescreen monitor and a detachable bluetooth keyboard. It's also expensive. But for those of us who would rather not have a big hunk of purest beige in whatever room houses your PC, this is an innovation to be welcomed – even more so if you'd like to be able to move your PC now and then (and given its weight, you're not going to want to carry it too far.) Hopefully, the creative juices of other PC manufacturers will start to flow.
I know of many, myself included, that switched from these stored proc based systems to using O/RM without stored procs, but I know no one that switched the other way
observes Paul Wilson in a recent post. I’ve had positive experiences with ORM tools, especially NHibernate – although for some the mindset change required can be a significant barrier – and I’ve worked on systems where stored procedures were a real problem (especially in terms of maintenance, versioning and performance.) The debate about ORM versus traditional data access techniques strikes me as a variation on the debate on managed memory versus unmanaged. Once you’ve lived in a managed world, you’d be reluctant to go back to an unmanaged one – but it doesn’t mean you stop paying attention to memory issues. Similarly, when you use an ORM framework, you should still be aware of how it works and what the impact of your decisions are.
Michael Feathers’ thought-provoking post about deprecating the use of final (sealed in c#) has generated a good discussion – judging by the comments. The discussion is about the use of final applied to classes and methods – not to instance variables (c# makes a distinction by using the readonly modifier for this usage.)
I rarely use final/sealed (I use final/readonly frequently.) Final/sealed makes your classes much harder to test. It can also make classes that use your classes harder to test. And since you care if your code works or not, you’ll avoid final/sealed. In addition to making testing more difficult, it conflicts with the open/closed principle – which may translate into increased maintenance issues. It also suggests a lack of trust in those using your code (which in the case of the java.lang.string example posed by Michael Feathers, may be appropriate.) I’d guess a lot of people choose final/sealed because they feel it will improve performance – I’d favour code that works (and the performance benefits may be insignificant.)