Head.SmackOnTable();

This seems to be a really controversial topic between developers. The "Old Skool" developers insist that Stored Procedures are better, faster, and more secure. Maybe 5 - 10 years ago this was the case, but unfortunately these days, it isn't.

"Its More Secure"

Err, not anymore its not. You can have parameterised adhoc SQL :

That is fully functioning code (Albeit it wont work, because of no connection string etc etc etc). Sql Injection wont work with that code.

"Its Faster"

Since SQL 2000 SP4 (I think?), SQL Server now caches the execution plan for adhoc queries too - assuming you run the same query, and only change parameters. And if speed REALLY is an issue, instead of trying to squeeze 0.004% extra speed out of the query (WOW It runs in 58.9 seconds instead of 59 seconds!), maybe have a look at clustering the database.

Other reasons I don't like Stored Procs

People who insist that you have to write stored procedures for all database operations need their head examined. Writing a stored proc for simple CRUD is a waste of developer time, and violates the DRY principle. There is simply NO point in writing a stored procedure that will insert a record - you can simply do that from adhoc sql, and it will be easier to manage.

If you have logic in your stored proc, then you should read up on n-Tier applications, and separation of logic. The stored proc's are simply an extension of the Data Access tier - the DA's tier is simply to fetch the data. IT SHOULD NOT HAVE LOGIC inside it. That's the job of things higher up.

Personally, I think writing SQL statements for CRUD is soo 1999. We have code generators, we have libraries to speed things up. In the 2 years, I havnt really seen a reason to hand write SQL code for use in apps. Simply point a code generator towards it, and hit the magic button, and you have all your CRUD for you.

Even things like nHibernate I dont agree with - personally I see them as DRY violators too. You have to declare the name of the table in the database, then in the code. You have to declare a column in the database, then use the same name in the code. Where you have more than one point you have to declare something, you will run into problems where one of them isnt upto date.

Iv spent the last 3 hours looking into the Facebook.NET api, which is a headache. I would have expected alot better code from someone who is very high up in the .NET community. The issue is, when visiting this Facebook application, if you don't have the application added, this redirects you to add the application. I know this is wrong, because I read alot of the Facebook documentation, and it says you dont have to do this. After tracking down the code through alot of painful debugging (Facebook don’t make things easy), I came across this line:

Facebook.Web.FacebookFbmlSession.cs line 61

That piece of code, buried deep in the Facebook.Net framework makes a faulty assumption - you can only view this application if you have added it. I have proven you don’t need to do this, the only requirement is to have your self logged into the Facebook application.

Implications?

Basically, the way the Facebook.net API was written, if you want a user to interact with your application, they will HAVE to add the application - this is a pain in the arse for what im trying todo, since I only want certain people to have the application added (and stuff added to their profile) - for simple things like registering a vote, you shouldn't need to have the application added - only their uid (user id), and we can do the rest.

Way forward?

Well im taking out that line, since it makes a wrong assumption. I'm not sure if it was an oversight on the developers side, or wishful thinking.