Currently we are starting up a project to rewrite the security service. The previous version was build using data sets (argh it even gives me the creeps just writing this word), relying heavily on the database. For every change (big or small) on the user profile the entire thing was deleted out of the database and the new version was inserted. It even came this far that with large profiles, the timeout of the web service was hit and the application refused to work altogether. Lessons learned from this debacle, we decided to build a clean domain model and use a UnitOfWork to decide what needs to be saved into the database. We added features like lazy loading and caching as well to avoid database payloads. Then we decided, based on the patterns already examined, we would need an ORM. We looked at some possibilities (Allors, NHibernate, ...) , did some spikes and decided that when building a Persistence Ignorant domain model, Nhibernate was the best choice.
We presented our findings and spike results along with our proposed solution to the enterprise architects. It was turned down for no apparent reason. Their solution was to align with the rest of the organization and go for a data-driven approach (they even mentioned data sets) and thus avoid complex domains that need mapping through a tool. In case of caching, we were told to write it in stored procedures (because that is why they are there for :-)). "Why on earth did we even have a complex domain model" was the last question of the meeting. This coming from a team that believes that writing unit tests is more time consuming than it is beneficial. Wait until they have to maintain one of these data-driven applications :-).
We lost this battle, but we didn't surrender our fight. We already assembled some followers:
- The DBA team loved the caching and the reduced database hits.
- Other development teams were experiencing the same problems so were asking for similar solutions.
Long story short, the decision to use it or not was postponed until a meeting were both us and the A-Team would present our cases. The meeting was last Monday and given this blog posts title our arguments have won it.
Thank God because we already started on the ground work of our own ORM and it would take a lot of work to build the features we are now getting for free! We've worked about two weeks on it and I think we could cover about 75% percent of our basic CRUD operations. We didn't yet added support for collections the UnitOfWork, but we already had ideas about how to do it (build a custom persistent collection for it). Our implementation depended heavily on the dynamic proxy of castle project and was inspired by the NHibernate source code. Writing it ourselves made me think about this scene from the matrix were Morpheus asked Neo to take the blue pill and stay ignorant (about persistence issues) or take the red pill and see what really going on. We were forced to take the red pill or doom the project before it even began. It was fun to experiment with it, but when your problem domain is security, that should be the focus of your development all time you spent on infrastructure code is time wasted!
Anyway we are going to test NHibernate in our project, then it will be evaluated and eventually rolled out to the rest of the development teams. Lets start reading about it!
See ya next time.
