V-Base Development Blog

We have just started yet another refactoring iteration. The last one for a wee while, I’ve been told. It’s nice to have had the chance to take a step back and change some of the things that can come back and bite you later. In the previous refactoring iteration we concentrated on changing the way the database was structured and started with a schema that barely fit on an A3 page even with the smallest possible font and ended the iteration with a schema that shows quite clearly on an A4 sheet. The same functionality with less complexity. Success!

So this iteration we are aiming at the domain and the gui code for one of the main areas of the application. We will be shifting the gui components from autonomous views (gasp) to a version of the presentation model called Model/View/ViewModel . This is a pattern that is fairly simple to implement with WPF’s excellent data binding model. The main reason for implementing this model is the fact that it makes it easier to test gui components in code but as it’s similar to the MVC model it also has other benefits. We have all successfully used this pattern to implement and test the latest gui components that we have written in recent iterations and this iteration we will be going back and converting the older code over to this model so that we can properly test them. Rise ohh rise almighty coverage value…

At the same time we will be adding an entity translation service in to convert from the nHibernate data classes to a true domain level entity for volunteers. This will allow us to get around a few problems we have with our usage of nHibernate. We have always generated the data classes from the the mapping files. This is setup as part of the build process and works very well. We have a modified version of the nHibernate hbm2cs tool that generates partial classes so that we can extend the generated classes without having to worry about custom code being overwritten the next time you run a build. This unfortunately only goes so far. We still needed a way of adding in business rules and validation rules to the properties of these classes in the generated code. We could have beaten the code generator with a stick until it allowed us to implement these features in the nHibernate classes but I just didn’t like that idea. It seemed to me that an entity translation service and a new domain level class would be a more effective solution for our rules problem and also for better separation of the application layer from the data layer. It also means all those strange things you have to do to get your data stored in a database can be hidden in the entity translation service which in turn can be hidden behind the volunteer service layer. Then you can have an application layer class that works the way you would like it to work and don’t have to let the database schema and nHibernate dictate the way your application is coded. Maybe I’m just a control freak but that sounds good to me.