LINQ to SQL blurs seperation of concern?

Question

I'll just put it out there that I'm new to LINQ to SQL. Hell, i'm relatively new to programming in general.

Anyways, I would like to learn and use LINQ to SQL to a project that was built using .NET 2.0 Framework. The project uses stored procedures to access the database (there's no dynamic SQL queries on the front end servers). LINQ to SQL seems a great alternative to stored procs but to introduce it to my project would break the principle of 'Separation of Concern'. Would it be best to not break this principles and just write more stored procedures when needed? Or is there a way to use LINQ to SQL without breaking the principle?

I generally find it hard to add new technology and tools in legacy projects without breaking the consistencies in projects.

Answer 1

Actually, LINQ to SQL helps a great deal with SoC. It separates the fact that you are using SQL from your domain objects even more than a traditional sproc-based DAL. Having a bunch of methods which call into stored procedures is a poor-man's attempt at the same thing - minimizing but not eliminating contact points between the DAL and the business logic. The LINQ to SQL library becomes your DAL, and you're free to manipulate a bunch of stupid objects with no direct ties to any data backing - with the added benefit of being able to express directly against your domain objects using LINQ expressions, instead of relying on the pre-determined permutations of stored procs.

Answer 2

Having code which interacts with the database server through SQL instead of through stored procedures is not a violation of separation of concerns, as long as that code is well modularized and the LINQ to SQL part cares only about data entry/retrieval and is not intermingled with other tasks (concerns). LINQ to SQL usage does not break any principle

Now, modifying code not to use SPs when it has been coded that way from the beginning will probably not be a small task and there might not be any real benefit in the end other than you learning LINQ to SQL.

Answer 3

If the project is a large one and uses many sprocs then it is not a smart idea to replace it's sprocs with LINQ. The reasons should be obvious why it is not prudent to do so. However, moving forward, this in no wise means you shouldn't implement a layer for LINQ. This is what I have done with some of my larger legacy apps. Implementing and using LINQ is well worth the effort, but it is not worth the effort (nor worth the risk) to rewrite old sprocs to use LINQ.