切换到LINQ

LINQtoSQL的优点是它不会在编译代码中真正嵌入查询——实际上不是。Linq语句意味着.Net代码实际上具有构建嵌入的Sql语句所需的逻辑,而不是原始Sql语句。

让.Net代码直接转换为Sql来执行,而不是一长串存储过程和相关文档,这确实很有意义。Linq方式更易于维护和改进。

我不认为我会将一个现有的项目切换到Linq——实际上它是整个数据层的替代品,它可以改变对该层的所有访问方式。除非你从一个非常相似的模式转换,否则成本对于任何潜在的收益来说都太高了。

LINQtoSQL的真正威力在于快速创建新的应用程序——它允许您非常快速地创建数据层代码。

我理解你的观点,这确实看起来有点倒退。。。

实际上,我可能会从LINQ转向SQL,更多地关注LINQ到实体,您的实体为您的概念数据模型建模,我个人觉得在我的代码中重新将查询嵌入概念模型会更舒服。实际的物理模型由实体框架抽象出来。

http://msdn.microsoft.com/en-us/library/bb386992.aspx

这是一篇有趣的文章,讨论了两种方法的优缺点: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm

编辑 另一个想法是,如果你不想等待EF,看看NHibernate,你也可以这样做。。。看见 http://www.hookedonlinq.com/LINQToNHibernate.ashx

我发现,只要有一个明确的DAL,并且您只是在不影响与消费代码的契约的情况下更改实现,就可以开始逐步将现有解决方案转向LINQ到SQL。参考列表是一个简单的候选对象,因为它们是低影响的只读数据集。如果您已经手工编写了类名来为数据库建模,那么您需要注意的主要问题是,如果您已经对类名进行了修改,那么可能会出现不明确的类名。

在将LINQ to SQL引入大型企业(从CTP时代开始)方面,事后诸葛亮很有价值,我很快就会再次这么做。它并不完美,也存在一些问题,但它有巨大的好处,特别是在开发速度和可维护性方面。这是一个新的范例,绝对是向前迈出的一步。

LINQ to SQL的实现不仅适用于SQL Server数据库,因此非SQL Server开发人员也可以利用这种高效的ORM。 我们已经添加了对查询级别LaodWith()的支持,并扩展了错误处理。 我们还计划支持所有三种继承模型(TPH、TPT、TPC)和关键字段生成。 您可以找到受支持数据库的列表 here

我不认为它是在代码中嵌入SQL,就像在代码中嵌入存储的进程名一样。对Proc的更改通常涉及对代码的更改。例如,通常需要添加新的in/out参数或更新getter/setter方法以引用新列。