Validation is one of the most important objectives when crafting a domain. Domain objects must be sheltered from invalid property and method arguments. Moreover, it is sometimes necessary to explicitly validate an object's state, for example to enforce business rules. This is the second post of a three-part series that discusses the use of the ValidationAspects aspect library in different application layers to do this, this time looking at NHibernate integration...
NHibernate uses lazy loading by default, which is generally a good thing. But when applied to polymorphic objects, this can lead to unexpected behaviour and serious problems - the first two parts of this series talked about that. This post - together with its predecessor - demonstrates a technique to make NH create lazy-loading proxies for a concrete subclass instead of for an abstract superclass, thus avoiding some quite nasty, hard-to-debug and hard-to-understand pitfalls...
Previously, I described a problem with O/R-mappers like NHibernate that could possibly break domain code which is relying on type information (this is not only relevant for casting issues!). The problem occurs when NH creates a lazy loading proxy for a polymorphic object, not knowing the exact type of the proxy at creation time. This post presents the first part of a possible way to circumvent these problems and to be truly persistent ignorant - not just physically, but also logically...
Setting up NHibernate is not one of the easiest tasks, and having to do it for each of your relevant test projects again and again certainly doesn't make it better. So here's a small base class for a test fixture that comes with already pre-configured, ready-to-use NH-support...
A few days ago, I talked about a problem, that using an ORM like NHibernate could bring, when there's inheritance and lazy loading around. Unfortunately, the example in this post turned out to be somewhat unclear, giving the impression that type casting issues are relevant in some way. This is a short follow-up with another example, that hopefully underpins my arguments a bit more precisely.
Recently, I came across a problem with NHibernate (and ORMs in general), lazy loading, and polymorphism. Initially I thought it to be just another one of these fancy technical details that one has to deal with all the time. But now I consider it to be a 'real' problem that can question our entire approach to architectural layering.
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.
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...