Thread: Stored Procedures VS nHibernate

I've started building my first "big" prject,

i'm making a CRM application with a friend and we dont know what kind of Database Layer to do,

we are using SQL server 2005,
and we dont know if to user StoredProcedures or nHibernate (at first we did all of the sql code generation i C#, after that we heard of StoredProcedures and changed everything to SPs)

i understood that using SPs to insert/update/delete data from the database is the most simple way of doing things through the ADO.NET but it is a very static way of doing things compared to nHibernate where you declare all your DB in an XML and everything else just going by that XML (while i couldnt really figure how to use nHibernate)

is nHibernate worth checking out and learning how to use it? (when i go find a real job as a c# programmer - will i ever use it again? )

Thanks

Personally, I don't even use "Stored Procedures" unless it is ABSOLUTELY needed. I try to keep everything inside my app code instead.

Edit : Simplicity is the key in my humble opinion. Less is more.

From what i understood the reason for using StoredProcedures is to prevent SQL injetions, when you generate the sql command with c# the user can insert sql code and do what ever he pleases,

SP commands are precompiled and getting parameters who fit the compiled command..

is there another way of preventing SQL injections?

and from what i understood companies who use Bussiness Objects normally use nHibernate - to create a code that doesnt rely on DB type (sql/oracle..etc) and names while all the DB tables and fields are mapped in an xml that nHibernate uses so changing it afterwards is easier,
is it true that most of the big companies (who use .NET enviroment) use nHibernate?

No, you can prevent injection with SQL Command as well :

Code:

MyCommand = DB.CreateCommand();
MyCommand.CommandText = SQLString;			
MyCommand.Parameters.Add...

every org that I've consulted has used stored procedures.

In larger applications there can be upwards to 1000 stored procedures which sounds like a lot but those are being re-used in multiple places in the app.

If your db is getting hung up on something it's a lot easier to find which SP is causing the issue and then just fixing it in one spot instead of having sql sprinkled throughout the entire application, so in my opinion it is better for maintainability.

With SOA being the new buzz word you will probably see nHibernate being used more and more but technology is usually one step behind theory in my experience so I think the new norm now would be SPs with nHibernate being the optimal solution.

doesnt rely on DB type (sql/oracle..etc)

This is a good idea, I just billed this client for three weeks to get their application to work with both SQL and Oracle simultaneously. This was expensive for them as you could imagine.