You don't have to put your SQL code into stored procedures to get the benefit of SQL injection protection. You only need to make sure that you use parameters in your SQL like this: "SELECT * FROM MyTable WHERE ID=@ID" and then declare the @ID parameter on the command object. Using parameters will also ensure that SQL server is able to optimize and cache the query plan for later. Most DNN stored procedures I have seen are just thin wrappers around some SQL INSERT, UPDATE, DELETE and SELECT. They don't add much value beyond making the task of changing the schema a time consuming pain.  One use-case where a stored procedure makes sense is when you insert into a table with an identity field. Not uncommon in the DNN world. Using a stored proc to insert, select and return the new identity value saves one roundtrip to the database. That would be worth the extra time and effort. Wrapping tens of different queries in thin stored proc wrappers. Not worth the effort in my view.