Follow aggregate pattern when using automapper

When using automapper, we tried to create one mapper class per entity, and it quickly became out of control.

One of the reasons is that we thought Mapper.Reset() is good enough to do the pre-clean-up, but the CreateMap from another Mapper class can also re-define the mapping relationship. Single Mapper works OK in unit-test mode, but when merge together in application, too many mapper classes became too many interferences.

We decide to go with aggregate pattern to solve this mess, mapping should be defined in the “root” mapper class per aggregate. Simple, clean and easy to manage.

A simple rule will be one mapper class per repository class.

Another very useful tip for automapper I learned today is: instead of catching AutoMapperMappingException and look Context, it’s much easier just call this before do any actual map operation

Mapper.AssertConfigurationIsValid();

It will give out more accurate error message in your mapping configuration, saved a lot of time. The message in context in exception is too general and useless.

Advertisements

1st day of NHProf

Finally, I got some time to try this must-have tool for NHibernate, downloaded it, asked for the trail key, why 33 days?

No changing to source code sounds a good idea, the assumption is using log4net appender, every NH project suppose use log4net, doesn’t it?

I’m not sure what NHibernate internal statistics is? (Ayende doesn’t recommend turn this on) Because we are using FluentNHibernate, there is no hibernate.cfg.xml file we can change, there is 2 solutions from stack overflow, but without seeing this xml file, how can I know it works? (BTW, how can I export hibernate.cfg.xml to somewhere like what we can do for hbm.xml?)

The result is, I can’t output statistics file for NHprof, so instance is the only way. Fortunately, it works. But, what if the port is being used? Or how to modify it? I couldn’t find it in NHProf.exe.config, it can’t be hardcoded?

     tcp://127.0.0.1:22897

Input from Ayende: Changing the port that the profiler listen to is done through the UI, Options > Settings

OK, back to our app, 5 Unbounded result set warnings and one N+1 select alert. Not too bad, the interesting part is, this N+1 select alert only appears in WCF client, not in domain service or repository layer.

It turns out the problem happens in AutoMapper which is doing the property loop through the result set from repository. Some properties are set to lazy-load.

We should beĀ  really careful when using AutoMapper, I think we should either explicitly exclude those lazy-load properties, or create a query to eager fetch those needed properties.

Thanks to NHProf, developers can figure out what’s extatly beneath their feet, ice or solid ground.