I an re-writing the London .NET User Group website which is old and long in the tooth. I like these personal projects because they form a great learning opportunity. I can explore new tools and frameworks without worrying about exposing an employer to ‘learning on the job‘. I have a number of learning goals on this project:
- ASP.NET MVC. I am using Monorail commercially and I am looking forward to getting a feel for the differences.
- Spark View Engine. I prefer templates that do not obscure the structure of the html and I’m looking forward to taking this one out on the road.
- SpecUnit. I have wanted to give an example-driven development tool a run out for a while now as part of efforts to pick up from the BDD guys.
- Fluent NHibernate. I’m a Castle Active Record user, but I want to find out if Fluent NHibernate offers me anything more.
I’ll probably give some feedback on all of these over the weeks, including fluent NHibernate in my NHibernate series.
Trial and Error
One really interesting idea is Fluent NHibernate’s Automapping. Fluent NHibernate is a great example of what is possible with static reflection. However, I found myself a little bit cool on automapping at first. I found it a little hard at first not knowing what the mappings were. I’m used to using Castle Active Record whose close association between attribute and mapped property or class makes this fairly explicit. I have always been less concerned by friction from representing orthogonal concerns as attributes so it took me a while to before I started to enjoy Fluent NHibernate’s ClassMap. Automapping pushed my comfort out even further because it was even more ‘under the hood’. Getting more comfortable here was a multi-step process.
- The first was using the explicit ClassMap files to become confident with the mapping, before tacking automap. Small steps.
- The second step was to hook up log4net (a good step with NHibernate anyway). Maybe its just reflex but when I get a persistence error one of the first things I want to do is look at how I was mapping. This meant I could refer to the generated xml for the mapping when I set the logging level to DEBUG. I generate the Db from the domain model using a separate console project I just run from the command line, so this simple step meant I could recover the feedback I wanted as to the mappings from that. That helped me see my mistaken assumptions or confirm that the automap was doing what I wanted.
- The last step is to use the built in support for integration testing that the Fluent NHibernate project provides. That gave me confidence that the mapping was what I wanted. James Gregory shows how here.
Finally, I suspect that you may need to be careful if your domain has a lot of exceptions. Exceptions may end up being confusing. I’m not sure that altering the conventions for the mappings that differ may not end up being less confusing than just explicitly mapping in the long run. I suspect there is a trade off here. If most of your classes conform to your conventions and you only have one or two exceptions this may be the way to go, but if you have a lot of variants then this may not be so helpful and you might be better off just using the explicit ClassMap<>.
My one oustanding concern is how people supply automap with criteria for the classes to map from the assembly. Your domain assembly will contain a lot of types which will be transient and not persisted. So you have to provide some selection criteria to pick the types you want to map out of the assembly. The danger here is that to make my selection criteria you might adopt a strategy of deriving from a base class or interface which does not have any value in your domain but is just a ‘marker’ for persistence. This reduces my adherence to Persistence Ignorance principles because my entity ends up being designed to meet the needs of a mapping technology. I suggest preferring to use criteria such as namespaces here.
