Thursday, November 17, 2011

Use tools only for what they are made for

I'm using NHibernate.Linq quite intensively for more than a year now and while I do know it better and better, I use it in less scenarios than before. Why is that? It's easy - there are some scenarios, where using it makes no sense. NHibernate's provider is just a tool, with its design, its features and its limitations. NHibernate.Linq is good in querying for business objects, as this is what it's made for. But we may get tired when trying to do some analytical or reporting queries or when processing data in batch mode. This is of course doable with Linq, but for sure not practical. And this is what plain old SQL is made for.

We, developers, often have some kind of unsaid belief that when we decided to use one specific tool, we shouldn't use another, similiar one. That makes sense when both tools offer exactly the same functionality or when using another tool causes significant performance penalty. But this is not the case with NHibernate.Linq and other database access methods. NHibernate is already bundled with both QueryOver and Linq, so we can use both without any penalties. We can also rely on ICriteria API, HQL or plain SQL queries if needed. We can even use ADO connection directly to totally skip NHibernate's layers. If this makes our task easier, why not?

Good cook always have a lot of knives in his kitchen and he knows that one knive is for fish and other for vegetables. There's no such thing as universal knive to cut everything. The same for us - it's important to be aware what each tool is the best at, to know which one to use in particular situation and try not to look for universal tool "to rule them all".

1 comment:

  1. I agree that there is no a universal knife to cut everything. Even creating your own data access layer and object mapping (modelling) isn't a bad idea. Thanks for this!