我有一个现有的网络应用程序，它有一个数据层和一个调用数据层的bll。数据层是调用存储过程的ado.net。
我在vs.net中为linq-to-sql创建了另一个项目，拖了我所有的表。
开始使用linq是明智的还是我应该花时间在linq中重写所有数据库逻辑，这样我就没有任何问题有2个数据层！
答案 0 :(得分：1)
如果没有损坏，请不要修理它。
为什么要完全重写完美的数据层？ ADO.NET +存储过程是一个很好的选择。收下。与此同时，您可以开始使用LINQ。
无论如何，在您能够决定新的数据层架构之前，您需要对LINQ进行一些练习，以了解它可以做什么以及不能做什么。在某些情况下LINQ无法立即处理，因此您需要使用技巧或用您自己的查询替换默认实现。在你决定的那天结束时，这是不值得的。
我的建议是分别获得一些经验，而不是仅仅因为LINQ很酷就开始重写所有内容。
答案 1 :(得分：0)
除非您当前的数据层由于某种原因而中断，否则不要只是因为可以开始实施新的数据层。
虽然如果当前数据层包含使用存储过程并且维护起来很麻烦，那么切换到L2S（或任何其他OR / M）可能是一个正当理由。只是不要认为只是将一些列拖到画布上就可以了。依赖于sprocs中的任何逻辑，逻辑必须存在于某个地方......
我要说的是，除非您能够证明切换数据层的成本是合理的，否则请坚持使用当前的实现。
答案 2 :(得分：0)
请注意：Linq和LinqToSql之间存在重大差异。 Linq很棒，如果可能的话你应该使用它。 LinqToSql不是很好，有很多问题：
Do not use the Visual Studio 2008 LinqToSql O/R Designer
The drawbacks of adopting Linq To Sql
要使用Linq，您需要某种ORM。在.NET世界中，ORM有很多选项。如果您喜欢LinqToSql提供的内容，那么使用SubSonic可能会非常舒服。从长远来看，NHibernate是目前.NET ORM的最佳选择。我在这里写了很多关于选择.NET ORM的文章：
.NET and ORM - Decisions, decisions
最后，没有理由不能在同一个应用程序中拥有两个或更多不同的数据层技术。但是有充分的理由不这样做，所以如果可能的话应该避免这样做。
此外，这是针对使用存储过程的引人注目的写作：