NHibernate's EnumStringType class is a custom user type to realize an arbitrary mapping between an enum in your domain code and a related set of strings in your database. While playing around with it, I stumbled over some strange behaviour that turned out to be a bug in NH's codebase. It took me two days to finally nail down the problem. This is a short recap of my findings, that hopefully prevents some other poor developer souls to get stuck with the same problem...
In some scenarios, you may have a database that contains text data in a column which is restricted to a certain set of discrete values. In such a case it is a good idea to use an enumeration for representing these data in your domain. This post demonstrates an easy and effective way to put this mapping under test.
Stumbled across a funny video this morning:
An Introduction to the Lego Software Process from Thomas Hansen on Vimeo.
This video is taken from the website The Lego Software Process, which states further:
"For far too long Software Developers have been living in the stone age. The Lego Process proposes a Modular design. This makes you 20 times as productive. In addition it also makes maintenance a breeze, bugs vanish and security a commodity.
Imagine;
- 20x Productivity
- No Maintenance Problems
- And Zero Bugs"
I like the video, and I also like the first few paragraphs of the accompanying manifesto, they describe the current situation of software development quite clear. But this is far too much to be taken seriously.
And BTW: The discipline of software development is in stone age, it's only about 50 years old. And simply declaring that this is over now doesn't help...
A situation, that most developers might know from personal experience:
The project is nearing the deadline, and there is far too much work left to be done. Usually the consequence is, that the remaining features of the software will be implemented in a quick-and-dirty way, leaving aside quality related issues like e.g. proper design or adherence to coding standards for the moment. - Much of today's spaghetti code is born this way.
- The common excuse for that is: "We'll do that later. Now our first priority is to meet the deadline." In most cases, this goes with considerable pressure, usually from management.
But the very short answer to that is: "No!" The slightly longer answer would be: "If we don't do it now, we won't ever do it at all. We still can decide to do so, but one has to be aware of the trade-offs that come with this decision."
I don't know how often I heard this notorious "we'll do that later" - statement during the last few years - but I know exactly how often this turned out to be true: Never. It's just not going to happen. When the deadline was finally met, some other (of course very urgent) work will stand before your desk right away.
- Besides the fact that "we'll do it later" actually means "we won't ever do it", there are some other aspects that come with this:
- You agree to deliver a product that does not meet the usual quality standard.
- Changing a system after it was released to the customer is much harder than doing so before the release, comes with much higher risks and for sure produces significantly higher costs.
I don't want to say that the"we'll do that later" - decision is avoidable or even worth avoiding in any case. But everyone who accepts it should know that this is actually a decision not to do something and that there is a price to pay...
During the last days and weeks, there's an increasingly heated debate about the performance of NHibernate vs. some other commercial and noncommercial ORMs. While there may or may not be good arguments for both sides, the discussion seems to miss the point...
Having an enum in code that corresponds to a database table is a common scenario in enterprise application development. - For example you may have an 'OrderStatus' enum in your business logic and a corresponding database table 'ORDERSTATUS' in your database. In such a scenario the enum-table relation might be at risk to go out of sync. This post introduces a simple but useful unit test fixture, that keeps an eye on this for the entire project lifetime...