这里的每个人都跳上了ORM乐队的旅行车吗?

时间:2008-12-12 16:18:30

标签: c# .net nhibernate linq-to-sql orm

Microsoft Linq to SQL,Entity Framework(EF)和nHibernate等都提议将ORMS作为下一代数据映射技术,并声称它们轻量级,快速且简单。例如刚刚在VS杂志上发表的这篇文章:

http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

谁都对在项目中实施这些技术感到兴奋?这些技术的创新在哪些方面比他们的前辈更加优秀?

19 个答案:

答案 0 :(得分:17)

多年来,我已经在数百个应用程序中编写了数据访问层,持久性组件,甚至我自己的ORM(我的一个“爱好”);我甚至已经实现了自己的业务事务管理器(在其他地方讨论了SO)。

ORM工具已经在其他平台上存在了很长时间,例如Java,Python等。现在看来,以微软为中心的团队已经发现了一种新的时尚。总的来说,我认为这是一件好事 - 这是探索和理解建筑和设计概念的必要步骤,这些概念似乎随着.NET的到来而被引入。

一句话:我总是喜欢自己做数据访问,而不是打击一些试图“帮助”我的工具。放弃对命运的控制是绝对不可接受的,数据访问是我应用程序命运的关键部分。一些简单的原则使数据访问非常易于管理。

使用模块化,抽象和封装的基本概念 - 将您平台的基本数据访问API(例如ADO.NET)与您自己的图层一起包装,从而将抽象级别提升到更接近您的问题空间。不要直接针对该API编码所有数据访问(也在SO上的其他地方讨论过)。

严格应用DRY(不要重复自己)原则=重构数据访问代码中的日光。在适当的时候使用代码生成作为重构的方法,但是尽可能地消除对代码生成的需要。通常,代码生成表明您的环境中缺少某些东西 - 语言不足,设计工具限制等等。

同时,学习如何使用可用的API,特别是关于性能和健壮性,然后将这些课程纳入您自己的抽象数据访问层。例如,学习在SQL中正确使用参数,而不是将文字值嵌入到SQL字符串中。

最后,请记住,任何成功的应用程序/系统都会遇到性能问题。修复性能问题更多地依赖于设计它们而不仅仅是“调整”实现中的某些东西。该设计工作将影响数据库和应用程序,它们必须同步更改。因此,寻求能够轻松(敏捷)进行此类更改,而不是试图避免不断更改应用程序本身。在某种程度上,这最终意味着能够在不停机的情况下部署变更。如果你没有“设计”它,那就不难做到。

答案 1 :(得分:12)

我是一个巨大的ORM倡导者。使用ORM生成代码可以使我的商店在大多数项目中节省大约20-30%。

我们合同开发,所以这是一个很大的胜利。

Chris Lively提出了一个有趣的观点,即每次触摸查询时都必须进行重新部署。对某些人来说这可能是一个问题,但它根本不会触及我们。我们有直接修改生产数据库的规则。

此外,你仍然可以依赖传统的sprocs甚至适当的视图...我们不是教条100%ORM,这是肯定的。

答案 2 :(得分:6)

自从LLBLGen的免费版本发布到最新最好的商业产品LLBLGen Pro以来,我一直在ORM火车上工作。我认为ORM非常适合许多常见的数据输入输出系统。

这并不是说他们解决了所有问题。它是一种可以在有意义的地方使用的工具。如果您的数据库架构与业务对象的相关性非常接近,那么ORM就是最好的。

答案 3 :(得分:6)

跳起来不是一个潮流,是对真正问题的反应!对象关系映射(ORM)已经存在了很长时间,它解决了一个真正的问题。

原始面向对象(OO)语言都是关于使用计算机语言模拟现实世界的问题。可以说,如果您真的使用OO语言来构建系统,那么您将使用域驱动设计(DDD)模拟真实世界的问题域。这在逻辑上将您带到一个关注点分离模型,以保持您的DDD清洁和清除数据持久性和应用程序控件的所有混乱。

当您按照DDD模式构建系统并使用Relational数据库进行持久化时,您确实需要一个良好的ORM,否则您将花费​​太多时间来构建和维护数据库crud(双关语)。

ORM是一个老问题,几年前被Object Lens和Top Link等产品解决了。 Object Lens是ParkPlace在90年代建造的Smalltalk ORM。 Top Link由Object People for Smalltalk构建,然后转换为Java,目前由Oracle使用。 Top Link自90年代以来也一直存在。 DDD倡导者现在开始清楚地阐明DDD的案例并获得思想共享。因此,ORM必然会成为主流,微软只是像往常一样做出反应。

答案 4 :(得分:5)

没有。不是每个人都是。

这里有大多数ORM工具的房间里最大的大象(特别是LINQ to SQL:

您可以保证,任何与数据相关的更改都需要完全重新部署您的应用程序。

例如,我的日常工作目前可以通过修改现有存储过程并重新部署这一个来解决大多数查询问题。使用Linq等人,您的数据查询将被移动到您的实际代码中。猜猜这意味着什么?

答案 5 :(得分:4)

对于那些与为他们编写软件的软件相处良好的人而言,ORM是一个很好的匹配;但是如果你对控制正在发生的事情以及为什么这么做有着强迫性,那么ORM可能不是最理想的,特别是在数据库优化方面。任何抽象层都有成本和收益; ORM既有,但余额还不对恕我直言。而ORM,以其当前的形式,具有讽刺意味的是添加了一个抽象层,仍然将类和未经反应的数据库模式紧密地放在一起。

我的经验是,它可以帮助您快速获得概念验证版本,但可以引入您可能不熟悉的重构要求(至少尚未。)

除此之外,该工具正在不断发展,最佳实践和模式尚未完善,也没有让其他程序员(或未来程序员)对代码感到满意的一致意见。所以我希望看到一段时间内的重构要求高于平常。

我将保留(乐观地)关于它在主流方面的定位的判断。我现在不打赌当前的项目。我处理阻抗不匹配的模式对我来说是令人满意的。

答案 6 :(得分:2)

我期待着我的团队开始研究ORM解决方案的那一天。直到那天,我们才是一个纯粹的DataSet / Stored Procedure商店,让我告诉你,并非所有的饼干和肉汁都是“纯净的”。

首先,新的Linq to SQL的性能与存储过程和数据读取器的性能接近。我们在任何地方使用数据集,因此性能会提高。到目前为止ORM非常好。

其次,存储过程具有单独发布代码的额外好处,但它们也不利于单独发布代码。假装有一个数据库,其中有超过5个系统连接到它,超过10个人正在使用它。现在考虑管理所有这些存储过程更改和依赖项,尤其是在存在公共代码库时。这是一场噩梦...

第三,调试存储过程很困难。由于各种原因,它们经常导致错误的行为。这并不是说ORM生成的动态sql不会导致同样的问题,但少一个问题就是少一个问题。没有权限问题(尽管大多数在SQL 2005中解决),没有更多的多步骤开发。编写查询,测试查询,部署查询,将其绑定到代码中,测试代码,部署代码。查询是代码的一部分,我认为这是一件好事。

第四,您仍然可以使用存储过程。运行一些需要很长时间的报告?存储过程是更好的解决方案。为什么?查询执行计划可以由数据库引擎优化。我不会假装理解数据库的所有工作,但我知道当前优化动态sql存在一些限制,这是我们在使用ORM时所做的权衡。但是,使用ORM解决方案时不会排除存储过程。

我认为人们避免使用ORM的最大原因是他们根本没有经验。将有一个明显的学习曲线和无知阶段。但是,如果要提高开发性能并且几乎不会阻碍(或者在我的情况下改进)性能。这是一个值得做出的折衷。

答案 7 :(得分:2)

除了最简单的选择,更新或删除之外,您还需要与ORM系统作斗争。一旦你开始做真实的东西,你的表现就会进入厕所。

所以没有。

答案 8 :(得分:1)

我也是粉丝,使用EF和Linq-to-SQL。我的理由是:

由于LINQ是编译且类型安全的,因此您不会在“基于字符串的”SQL中遇到拼写错误的问题。我不知道我花了多少时间来追踪SP或其他SQL中的错误,其中“tick”或其他关键字位于错误的位置。

以上和其他因素使发展更快。

虽然与“更接近金属”的数据库查询方法相比,确实存在开销,但如果性能是我们的第一关注点,那么我们都不会使用.NET,甚至不会使用C ++。对于大多数应用程序,我已经能够从Linq-To-SQL获得出色的性能,即使不使用存储过程方法(基于客户端的编译查询是我通常的方法)。

当然,对于某些应用程序,您仍然希望以传统的方式做事。

答案 9 :(得分:1)

我想我的意思是,ORM在使用传统的ADO.NET,SQL并将它们映射到代码中的对象的过程中提供的创新是什么?

以下是我的DAL的三个主要方面,我正在与ORM进行比较以了解其优势:

  1. 您仍然需要在ORM = SQL中进行查询(到目前为止SQL更强大)

  2. 映射代码移动到配置但仍未消除,只是从一个范例转移到另一个范例

  3. 与传统方法不同,对象必须与数据模式紧密相关地定义和管理。

  4. 我错过了什么吗?

答案 10 :(得分:0)

我正在努力在.NET中编写一个ORM工具作为一个让我受理的副项目。

SQL对我来说已经死了。我讨厌写它,特别是在我的代码中随处可见。手动为每个对象编写select / insert / update / delete查询是浪费时间IMO。在动态生成查询时,甚至不让我开始处理NULL(“其中col_1 =?”vs“col_1为null”)。 ORM工具可以为我处理。

此外,有一个地方可以动态生成SQL可能需要很长时间才能消除SQL注入攻击。

另一方面,我使用过Hibernate,我绝对讨厌它。在一个真实的单词项目中,我们每隔几周就遇到限制,未实现的位和错误。

保持查询逻辑数据库端(通常作为视图或存储过程)还具有可供DBA调整的优点。使用Hibernate,这是我上一份工作的一场持续战斗。 DBA:“给我们所有可能的查询,以便我们可以调整”Devs:“呃,我不知道,因为Hibernate将动态生成它们。我可以给你一些HQL和XML映射!” DBA:“不要让我打你的脸!”

答案 11 :(得分:0)

我一直非常关注Fluent-NHibernate,因为它有一些我在项目中见过的最有潜力。

答案 12 :(得分:0)

  

如果codesmith根据您的表生成代码,您是否仍然与数据模式紧密耦合?我更喜欢一种解决方案,它将我的对象与我的数据库模式分离,以便在架构中实现灵活性

这是你的一条评论 - 这是真的,CodeSmith将你与你的桌子紧密地联系在一起。

另一方面,NHibernate有许多功能可以帮助你:你有组件,所以在代码中你可以拥有:具有属性地址的人,其中地址是一个单独的类。

您还inheritance mapping。因此,它可以很好地将您的架构与您的域解耦。

答案 13 :(得分:0)

我是一个很大的ORM人,从数据库中获取逻辑,仅使用数据库来提高速度。

我喜欢你开发应用程序的速度。取决于ORM,最大的优势是您可以在不必翻译业务逻辑的情况下更改后端。

我切换到LINQ并且从未回头。 DBLinq对于使用除MSSQL之外的其他数据库非常棒。我已将它与MY SQL一起使用,它很棒。

答案 14 :(得分:0)

我不喜欢大多数ORM中使用的代码生成。事实上,一般来说,代码生成我发现它是一个弱工具,通常表明首先使用了错误的语言。

特别是对于.Net反射,我认为没有必要为ORM目的使用代码。

答案 15 :(得分:0)

还没有,仍然持怀疑态度;像大多数微软产品一样,我等待SP2或一年半之后才在产品环境中信任它们

并注意到,几乎每个人都推出的新东西,不仅仅是微软,都被称为“轻巧,快速和简单” - 带上一块盐。他们不会像利益/功能一样大声宣传问题/问题!这就是我们等待早期采用者发现它们的原因。

这不是为了贬低ORM或LINQ或类似的东西;我正在保留判断,直到

  • 我有时间评估它们,
  • 有些需要只有他们才能满足,
  • 该技术看起来稳定且受到良好支持,足以在我的客户的某个生产环境中冒险,和/或
  • 客户请求

请注意:我之前已经手动完成了ORM,并且工作正常,所以我对新的ORM系统寄予厚望。

答案 16 :(得分:0)

在我工作的地方,我们仍然使用手工卷制,重复切割的'D'Paste DAL。它非常痛苦,复杂且容易出错,但这是所有开发人员都能理解的。虽然它目前对我们有用,但我不推荐它,因为它开始在大型项目上迅速崩溃。如果有人不想进行全面的ORM,我至少会提倡某种DAL生成。

答案 17 :(得分:0)

不,我倾倒了ORM并转而使用了一个小屁股和一个OODB:Gemstone。更好的代码,更少的代码,更快的开发。

答案 18 :(得分:0)

寻找你感兴趣的贴纸↓↓↓
豫ICP备18024241号-1