是否有理由继续使用Linq到SQL,还是最好改用EF,NHibernate等ORM技术。
我们正在新的大型企业应用程序中使用Linq to SQL,该应用程序将存在很长时间。此新企业应用程序的动机是该应用程序是用Visual Basic普通编写的,并且由于Microsoft停止了对我们的支持,因此我们不得不重新编写该应用程序。似乎我们已经在那儿了,但是这次是我们的DAL(数据访问层)。
我已经读过这篇文章,但只能与EF的弱点进行比较。
是否有理由继续使用Linq到SQL,还是最好改用EF,NHibernate等ORM技术。
我们正在新的大型企业应用程序中使用Linq to SQL,该应用程序将存在很长时间。此新企业应用程序的动机是该应用程序是用Visual Basic普通编写的,并且由于Microsoft停止了对我们的支持,因此我们不得不重新编写该应用程序。似乎我们已经在那儿了,但是这次是我们的DAL(数据访问层)。
我已经读过这篇文章,但只能与EF的弱点进行比较。
Answers:
如果您已经在使用它并且没有遇到任何困难,那么我会在现有项目上坚持使用它。
Linq2SQL是一个很好的ORM,但它是有限的ORM-如果您想以比Linq2SQL提供的基本方法更复杂的方式映射对象,那么您将陷入困境。Microsoft在发布.net 4时确实修复了一些错误,但表示不会将资源用于扩展它。
我想说的是,如果您有一个相当简单的项目,并且使用寿命可能很有限,那么Linq2SQL是一个不错的轻量级选择,只要您注意不要将依赖项泄漏到各处即可。对于其他任何事情,我都会选择其他方式(例如NHibernate或EF),因为Linq2SQL几乎是死胡同。
还没有死,但是微软现在专注于实体框架。
我已经在小型项目上使用LINQ to SQL,它作为轻量级数据层非常好,我会考虑在类似大小的项目上再次使用它。LINQ实现本身真的很好,直到最近很多比NHibernate的LINQ项目更好。在使用L2S的较大项目中,由于L2S'DataContext'类的局限性,我发现很难提出自己满意的工作单元模式。试图用L2S实现“每个请求的会话”之类的东西看起来非常困难或不可能。
我也不会真的将L2S视为真正的ORM,因为它确实没有给您很多映射选项。您的班级设计确实需要遵循您的数据库架构(每个班级表),否则它将与您的每一步斗争。关于L2S,我不喜欢的另一件事是需要使用特定的类型(EntitySet
和EntityRef
)处理集合,引用和延迟加载。这意味着在不添加另一抽象层的情况下就不可能保持域模型ORM不可知。
我对L2S的另一个问题是仅依靠LINQ来生成查询。LINQ提供程序的编写非常好,通常为大多数查询创建了不错的SQL,但是我担心,LINQ无法很好地表达更复杂的查询。在这些情况下,使用L2S基本上必须恢复为调用存储过程,而(例如)NHibernate具有多个API(LINQ提供程序,QueryOver,HQL等),当您希望对生成的SQL进行更多控制时可以使用它们。
在L2S的防守了NHibernate的,有很多在得到它,并在项目运行的开销更少。
比死掉的恕我直言更稳定:
http://www.thinqlinq.com/default/LINQ-to-SQL-enhancements-for-2010.aspx
http://jonkruger.com/blog/2009/06/06/linq-to-sql-is-not-dead/
他们已经将改进工作转移到了Entity Framework上,如果该产品能够成功,它确实是需要的。期待有新内容,但对linq2sql的兼容性和错误修复会持续一段时间。
如果我没有记错的话,这个站点运行着很多linq2sql。
这很奇怪,但是我看到了很多这样的措辞(“ LINQ2SQL已死”),我不确定它的来源*。就像死掉的Windows XP一样。Microsoft已停止支持,并创建了一些新功能(在我看来更好),但是人们仍然可以自由使用XP,就像他们可以自由使用Linq2SQL一样。诚然,我在创建自定义DotNetNuke模块时使用Linq2SQL。但是,具有EF4中的新功能,例如代码优先开发(http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx)很难找到坚持使用Linq2SQL的原因。我看不到要更新代码的理由,但是对于新代码,我不知道为什么您不想使用EF4。
*不过,老实说,我对语义非常执着!我很抱歉给别人带来烦恼:)