After at least two years of Hibernate and NHibernate experience I can say that I know what’s going on, I can’t still say that I know very well (N)Hibernate but I wanna share some learnings.

• The logger is your best friend:
  When sometimes goes wrong, the logger (or at least a profiler) will help you, it’s awesome to play with a database like we play with objects but I have the feeling that sometimes we forget that on a couple of layers below we are doing some good old SQL!
• (N)Hibernate is not meant for:

• Bulk data manipulations: use sqlBulkCopy in (.net) or upgrade to a version > 3.1.1 on Java Hibernate
• Free developers from understanding the database: it’s nice to hide the DB structure but the DB is there, and it’s not OO!
• Free developers from understanding (N)Hibernate.
  I sow many times in developers this approach: entusiasm followed by criticism followed by hate It’s very easy to do simple things and terrible then to fix bugs or understand some stack traces. It’s a great library and it’s not easy to use. A copy of hibernate in action or of nhibernate in action should be always present in a team playing with it.
• Let you forget the profiler: as mentioned before it’s the best way to understand the complexity of your queries, it’s easy to end up with a cartesian product result from a query or execute unuseful queries, especially when playing with multiple joins and criteria queries.

Recently we migrated all our build scripts from a combination of bat files + msbuild to a couple of NAnt build files.

There are some reasons for this and some nice outcomes.

Reasons

First of all we wanted to have the same build scripts for Development, CI, QA, UAT and production Environment.

On the Dev machines we need to build, test and install few services (ms services, a web service and a web app).
On Cruise same as above but no installation of the services and, indeed some publishing of the artifacts.
The QA environment is as close as possible as the UAT/Production: it just needs installation scripts and a way to get the latest artifacts published by Cruise.
Using the same script gave us a great confidence when going to production: scripts were used every day by the QA, no surprises when going live.
We got completely rid of all the .bat files for 2 main reasons: they become messy after 1 year of patches/fixes/modifications and we can’t really achieve the goal of one script for all as we wanted.

After a short investigation on alternatives to bat+msbuild (boobs and rake) we went for nant.
We found boobs quite difficult to use and install (you need to build some libraries, install boo, etc…), in other words it does not came for free. Rake is a cool solution, we didn’t choose that cos 1) we were too lazy to install ruby everywhere (in production especially could be a problem) 2) our build, even if includes a client app, four services, a web app and a web services is fairly simple.

Nant is really a good translation from the Java Ant. It’s actually more than a one to one translation, it has more features and it’s somehow more powerful.

I really liked the functions for example. And the contrib project is plenty of nice, useful tasks ready to use.

Another important improvement on the build scripts was on the database scripts.
Again, migrated from few bat files to one script for all the needed tasks.
We had a lot of satisfaction using dbdeploy.net, it really speeds up the work, especially in the QA environment migrating the DB schema to the latest version keeping the data in.

Outcomes

Life easier for everybody: instead of calling a bat files with some parameters we had a file of properties (not a lot of properties, convention over configuration!) for each environment, it’s now harder to fail an installation. It’s also more clear of what’s going on thanks to the nant output log.

Maintenance it’s easier. There are only two files that you need to know. Tasks are pretty short and responsibilities isolated.
We kept also a low lever of dependencies avoiding imports and more than two level of dependency.

Sometimes rewriting everything from scratch is much easier than refactoring / patching.
It has been also interesting to write a build file after one year of development, usually it’s one of the first things you do in your project.

My suggestion is: if your build script causes problems, waste of time or if it just smells and it’s not clear what’s doing, try to spike out a different solution, the benefit could be enormous.