Hi, I have an existing web app that has a data layer and a bll that calls the data layer. The data layer is ado.net that calls stored procedures.
I created another project in vs.net for linq-to-sql, dragged all my tables over.
Would it be wise to just start using linq or should I spend the time and re-write all the db logic in linq just so I don't have any issues having 2 data layers!
If it ain't broken, don't fix it.
Why would you want to rewrite completely your perfectly working data layer? ADO.NET + stored procedures is a great choice. Keep it. At the same time you can start playing with LINQ.
Anyway, you will need some practice with LINQ to see what it can and what it cannot do before you will be able to decide on the new data layer architecture. There are some situations that LINQ cannot handle right out of the box, so you will need to use tricks or substitute default implementation with your own queries. At the end of the day you may have decided, it was not worth it.
My suggestion is to gain some experience with it separately and not start rewriting everything completely just because LINQ is cool.
Unless your current data layer is broken for some reason, don't just start implementing a new one, just because you can.
Although if currently the datalayer consists of using stored procedures and that becomes cumbersome to maintain, switching to L2S (or any other OR/M for that matter) might be a valid reason. Just don't think it'll be only a matter of dragging some columns to a canvas and be done. Dependent if there's any logic in the sprocs, the logic has to exist somewhere...
I'd say until you can justify the costs of switching your datalayer entirly, stick with your current implementation.
Please be clear: there is a major difference between Linq and LinqToSql. Linq is great and you should be using it if at all possible. LinqToSql is not great and has many problems:
Do not use the Visual Studio 2008 LinqToSql O/R Designer
The drawbacks of adopting Linq To Sql
To use Linq, you need an ORM of some sort. You have many options for ORMs in the .NET world. If you like what LinqToSql offers, you may be most comfortable using SubSonic. In the long run, NHibernate is the best choice for a .NET ORM right now. I wrote a lot more on choosing a .NET ORM here:
.NET and ORM - Decisions, decisions
In the end, there is no reason you can't have two or more different data layer technologies in the same application. There are good reasons not to do this however and so it should be avoided if at all possible.
Also, here's a compelling write-up against using stored procedures: