November 2009 - DDD on the Web

I’m a huge fan of NHibernate . It has excellent documentation and just makes the whole job of getting things into and out of the database much more enjoyable.  There is a whole series of posts on NHibernate from one of the committers, Ayende .  When Fluent NHibernate (FNH) came out, it was like butter on sliced bread.  FNH makes it even easier to use NHibernate. Ayende had a great post a while back on how to use Event Listeners.  That helped me to get to event listeners set up. What does an Event Listeners look like? Event Listeners namespace projectname.infrastructure.app.auditing { using System; using System.Security.Principal; using System.Web; using domain; using NHibernate.Event; using NHibernate.Persister.Entity;   public class AuditEventListener : IPreInsertEventListener, IPreUpdateEventListener { public string get_identity() { string identity_of_updater = WindowsIdentity.GetCurrent().Name;   return identity_of_updater; }   public bool OnPreInsert(PreInsertEvent event_item) { Auditable audit = event_item as Auditable; if (audit == null ) { return false ; }   DateTime? entered_date = DateTime.Now; DateTime? modified_date = DateTime.Now; string identity_of_updater = get_identity();  ...

I’ve run into this situation a couple of times over the years. Let me tell you, it is fun!!!!!!! (That’s sarcasm for the sarcasm impaired). The general scenario is something like this: at some point in the history of a department, usually a number of years ago, the department decided it needed to upgrade its technical infrastructure (I’m leaving that purposefully vague), and decided that it needed someone who had a significant amount (or significant enough) of domain knowledge to drive that decision. Often times, this means the SME learns enough to implement some sort of technical design. Usually, what they learned is not necessarily the most ‘robust’ technology. Sometimes, it is Access, but it could be DTS, VBScript, batch files, etc. At some later point, it becomes clear that the technical infrastructure is well short of being manageable, and so a directive from the department or a higher-level entity is issued that an upgrade is required. This could be an upgrade to C# or Java or, hell, Perl….something. What often happens though is that, since the SME built the original implementation, they often become a crucial component of the upgrade process. And this is when all hell can break loose. Every decision has to involve this person...

As seen in previous post , I used dynamic to replay events. The main reason to use it was to avoid long code using reflection in the infrastructure that would have made it hard to read. I’ll show several ways to do this dispatch with pros and cons in each cases. Dynamic The proposed solution was using dynamic. + Pros : there is no reflection code involved, code is very simple. - Cons : all state change (Apply) methods must have the same name. I made no performance test, so I cannot judge if perf is better or not. It seems that the DLR has a rather good cache when the same type is encountered several time, but only measures can tell. Handlers registration This is the current implementation in Mark Nijhof’s sample . The base class maintains a dictionary of Type/Action<T> association to dispatch events based on type. Since an Action<T> delegate must have a target instance, the delegate must be constructed from within the instance, in the .ctor. public class AggregateRoot <TId> { readonly Dictionary < Type , Action < object >> handlers = new Dictionary < Type , Action < object >>(); protected void Register<T>( Action <T> handler) { handlers.Add( typeof (T),e => handler((T)e)); }...