Hi Slaven,
Believe me, I've had enough flames thrown my way over the last few years over this issue and I have no energy to invest in any more arguments. I choose not to use an OR mapper and that is not going to change. If developers want to use NHibernate in their custom features nothing stops them from that, but I'm not going there any time soon myself.
The ORM crowd often asserts that it solves the multiple database support problem, but really I do not see a lot of projects actually supporting multiple databases well like mojoPortal does. It seems mostly theoretical. Show me any other projects you see that really support 5 databases like I do in mojoPortal.
While its true that any supposed performance benefits of using stored procedures is so small as to be hard to measure, there are security benefits that can be important and should not be dismissed lightly. Its certainly more work supporting stored procs in my experience. Originally I was using procs for pgsql, but now I only continue to use procs for MS SQL.
There are many formal environments out there where the dba will not allow dynamic sql because it makes their job difficult not knowing what rogue sql statements may be hindering performance. Using procs also allows hardening the installation by using a db user with only permission to execute the procs and no direct permissions on any tables. mojoPortal using MS SQL can be used in these environments where OR mappers will not be allowed. I think Oracle shops also tend to have DBAs and tend to be very formal as well, so to me its questionable whether a dynamic sql data layer for Oracle would have appeal in a lot of Oracle shops. I think many of them would rather have procs.
I do not like the way most OR mappers want to be the base class for business objects. This makes it an all or nothing thing you can either use it or not use it. If there was a way to abstract it so that a NHibernate data layer could be implemented like the other data layers as a service tier that would be cool, but its not like that, you would end up with a parrallel set of objects that really want to be the business objects and there is no easy way to get an IDataReader so its impossible to implement the same api with NHibernate as our existing data layers do.
To me, every developer should understand databases and sql, with OR mappers we are headed towards using a lot of wizard generated code that the developers don't really understand. I know sql well and I don't find it to be terribly difficult, its very straightforward.
When there is any problem I find it much easier to debug it when I can get straight to the sql code rather than have some big chunk of middle ware to debug through.
I also think OR mappers tend to have more overhead than I would like. For fast web sites you need to optimise and use IDataReader to get best performance. To me it seems silly to create a List of objects just to databind a dropdown or grid, its a lot of un-needed object creation that adds no value other than making things more object oriented. When you look at things like the PetShop application where MS showed how much faster .NET is than java, they did it by optimising this way. If they had valued pure theoretical OOP over actual performance they would not have beaten java.
Using code generation as a jump start I get very rapid development, so the supposed faster development of using OR mappers is not so big to attract me.
Best,
Joe