Can LINQ to SQL and traditional Stored Procedures co-exist?

Question

First, to be clear, I am not talking about LINQ to SPRocs.

I have an existing DAL that uses over a 100 stored procedures. This was created when this program was a web app. Now it is a winform app in a sometimes connected environment that uses a local db. I have left the existing DAL in place in the interest of time but am now finding

My question is are there any pitfalls I should be aware of to creating a dbml(datacontext) to my program to go forward with while leaving the existing DAL in place?

This would allow me to replace the existing DAL in small steps.

Answer 1

None that I know of. The DataContext can be thought of as just another application; the presumption is that your database can handle arbitrary application connections, provided the application is well-behaved. Linq to SQL uses standard SQL commands behind the scenes to accomplish its work, and is aware of typical things like record locks and transactions. I think your approach is sound.

Answer 2

Well, one potential pitfall you need to be aware of would be if one of your SProcs modifies the data of an object that your LINQ DataContext is currently using.

If you have optimistic concurrency locking in place, worst case, the LINQ entity couldn't be updated later on (since the underlying values in the database have changed "behind" its back).

This is really not a big problem - you'll have to deal with this anyway (concurrency amongst several users). Other than that I don't see any problems.

Marc