linq and stored procedure

Question

0.00/5 (No votes)

See more:

Hello everyone,

We have been running a very tight and shrewd discussions for a long time over the linq and stored procedure. The discussion point is that one of my team members always says when a project is done using linq then there is no need to write store procedure as linq is more secured than SP and my view point is that (1) whether the project is of linq or not it does nothing to do with store procedure, store procedure should always be written as a basic and standard for the application and (ii) securityzing the project is some thing else. He does refer to a question that we would not require to build 3 tier or n tier application when we use linq in the project as it automates the several things. I have referred several quotes and articles to him about linq and SP, but every time the discussion ends up with no conclusions. He always argues that a project can not be a 3 tier project or n tier project if we use linq, as linq automates most of the things so we need not classify or create DAL, BAL,etc.

I know his logics are not valid but I want somebody to put light on his own words and language and please do not just give a few more web links in reply otherwise we wont be able to reach to the conclusion as it always happens. Just explain in your simple language. I request you not to mark it as an article.

Thanks a lot.

Posted 22-May-13 19:59pm

winners6

Updated 22-May-13 20:00pm

v2

Add a Solution

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Rob Philpott · Answer 1 · 2013-05-22T20:27:00

Well, I'll offer an opinion as I don't think there really is an answer to this.

Personally, I prefer to use stored procs and ADO.NET rather than Entity Framework or LINQ to SQL. This is a somewhat old-fashioned approach and undoubtedly is more work but then everything is clear cut.

I don't understand the argument that LINQ is more secured. A good practice is to ensure that code can only access the database through stored procedures and not have direct access to the tables. This way, you enforce abstraction and the SPs become the interface to the database. This treats the database as a seperate entity and the DBA (or whoever) needs to ensure that any changes to tables are reflected in procs. This way you minimise the risk of rogue code damaging the database and its worth remembering that there may be many processes (different teams?) using it. At all costs database integrity is the most important thing and make sure you get all the appropriate constraints in.

If you need to fetch some data, then update the database based on that, if it can be done in a stored proc you remove the network hop and improve performance (and may get query plan benefits) but obviously that's only for simple updates. If you are working transactionally this will give you tighter transactions and reduce the chances of concurrency issues.

That said, I am from an Enterprise Solution Background. If the database is pretty simple, only one process attaches to it and if there isn't a DBA and the developers also manage the DB the newer approaches will save a lot of development effort and keep them happy that they're doing things the 'modern' way. I doubt you will see any performance benefits, tighter security or less errors though.

As I say, this is my opinion and this is a well argued matter.

linq and stored procedure

1 solution

Solution 1

Add your solution here

Preview 0

linq and stored procedure

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us