【发布时间】:2009-08-28 19:57:31
【问题描述】:
我有一个现有的网络应用程序,它有一个数据层和一个调用数据层的 bll。数据层是调用存储过程的ado.net。
我在 vs.net 中为 linq-to-sql 创建了另一个项目,将我所有的表都拖了过来。
开始使用 linq 是明智之举,还是我应该花时间在 linq 中重新编写所有数据库逻辑,这样我就不会遇到 2 个数据层的任何问题!
【问题讨论】:
标签: asp.net linq-to-sql ado.net
我有一个现有的网络应用程序,它有一个数据层和一个调用数据层的 bll。数据层是调用存储过程的ado.net。
我在 vs.net 中为 linq-to-sql 创建了另一个项目,将我所有的表都拖了过来。
开始使用 linq 是明智之举,还是我应该花时间在 linq 中重新编写所有数据库逻辑,这样我就不会遇到 2 个数据层的任何问题!
【问题讨论】:
标签: asp.net linq-to-sql ado.net
如果没有损坏,请不要修复它。
您为什么要完全重写您完美工作的数据层? ADO.NET+ 存储过程是一个不错的选择。收下。同时你可以开始玩 LINQ。
无论如何,在您决定新的数据层架构之前,您需要对 LINQ 进行一些练习以了解它可以做什么和不能做什么。有些情况下 LINQ 无法直接处理,因此您需要使用技巧或用您自己的查询替换默认实现。在一天结束时,您可能已经决定,这是不值得的。
我的建议是单独获得一些经验,而不是仅仅因为 LINQ 很酷就开始完全重写所有内容。
【讨论】:
除非您当前的数据层因某种原因而损坏,否则不要仅仅因为可以就开始实施新的数据层。
虽然如果当前数据层包含使用存储过程并且维护起来很麻烦,那么切换到 L2S(或任何其他 OR/M)可能是一个正当的理由。只是不要认为这只是将一些列拖到画布上并完成的问题。取决于存储过程中是否有任何逻辑,逻辑必须存在于某处......
我会说,在您能够证明完全切换数据层的成本合理之前,请坚持您当前的实施。
【讨论】:
请明确: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
最后,没有理由不能在同一个应用程序中使用两种或多种不同的数据层技术。但是有充分的理由不这样做,因此应尽可能避免。
另外,这里有一篇关于使用存储过程的引人注目的文章:
【讨论】: