这里的每个人都跳上了ORM乐队的旅行车吗？
Microsoft Linq to SQL，Entity Framework（EF）和nHibernate等都提议将ORMS作为下一代数据映射技术，并声称它们轻量级，快速且简单。 例如刚刚在VS杂志上发表的这篇文章：
http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
谁都对在项目中实施这些技术感到兴奋？ 这些技术的创新在哪里使它们比以前的产品更加优秀？
多年来，我已经在数百个应用程序中编写了数据访问层，持久性组件甚至我自己的ORM（我的一个“爱好”）; 我甚至已经实现了自己的业务事务管理器（在其他地方讨论了SO）。
ORM工具已经在其他平台上存在了很长时间，例如Java，Python等。现在看来，以微软为中心的团队已经发现了一种新的时尚。 总的来说，我认为这是一件好事 – 这是探索和理解建筑和设计概念的必要步骤，这些概念似乎随着.NET的到来而被引入。
一句话：我总是喜欢自己做数据访问，而不是打击一些试图“帮助”我的工具。 放弃对命运的控制是绝对不可接受的，数据访问是我应用程序命运的关键部分。 一些简单的原则使数据访问非常易于管理。
使用模块化，抽象和封装的基本概念 – 将您的平台的基本数据访问API（例如，ADO.NET）与您自己的层一起包装，从而将抽象级别提升到更接近您的问题空间。 不要直接针对该API编码所有数据访问（也在SO的其他地方讨论）。
严格应用DRY（不要重复自己）原则=重构数据访问代码中的日光。 在适当的时候使用代码生成作为重构的方法，但是尽可能地消除对代码生成的需要。 通常，代码生成表明您的环境中缺少某些东西 – 语言不足，设计工具限制等。
同时，学习如何使用可用的API，特别是在性能和健壮性方面，然后将这些课程纳入您自己的抽象数据访问层。 例如，学习在SQL中正确使用参数，而不是将文字值嵌入到SQL字符串中。
最后，请记住，任何成功的应用程序/系统都会遇到性能问题。 修复性能问题更多地依赖于设计它们而不仅仅是“调整”实现中的某些东西。 该设计工作将影响数据库和应用程序，它们必须同步更改。 因此，寻求能够轻松（敏捷）进行此类更改，而不是试图避免不断更改应用程序本身。 在某种程度上，这最终意味着能够在不停机的情况下部署变更。 如果你不“设计”它，那就不难做到。
我是一个巨大的ORM倡导者。 使用ORM生成代码可以使我的商店在大多数项目中节省大约20-30％。
我们合同开发，所以这是一个巨大的胜利。
Chris Lively提出了一个有趣的观点，即每当查询被触及时都必须进行重新部署。 对某些人来说这可能是一个问题，但它根本不会触及我们。 我们有针对直接进行生产数据库更改的规则。
此外，你仍然可以依赖传统的sprocs甚至适当的视图…我们不是教条100％ORM，这是肯定的。
自从LLBLGen的免费版本发布到最新最好的商业产品LLBLGen Pro以来，我一直在ORM火车上工作了很长时间。 我认为ORM非常适合许多常见的数据输入输出系统。
这并不是说他们解决了所有问题。 它是一种可以在有意义的地方使用的工具。 如果您的数据库模式与业务对象的关系相对接近，那么ORM是最好的。
跳起来不是一个潮流，是对真正问题的反应！ 对象关系映射（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必然会成为主流，微软只是像往常一样做出反应。
不，不是每个人都是。
这里是大多数ORM工具（尤其是LINQ to SQL）的房间里头号大屁股大象：
您可以保证，任何与数据相关的更改都需要完全重新部署您的应用程序。
例如，我的日常工作当前可以通过修改现有存储过程并重新部署该一个部分来解决大多数查询问题。 使用Linq等人，您的数据查询将移至实际代码中。 猜猜那意味着什么？
ORM非常适合与那些为他们编写软件的软件相处的人; 但是如果你对控制正在发生的事情以及为什么会这么着迷，那么ORM可能不是最理想的，特别是在数据库优化方面。 任何抽象层都有成本和收益; ORM既有，但余额还不对恕我直言。 而ORM，以其当前的forms，具有讽刺意味的是添加了一个抽象层，仍然将类和未经反应的数据库模式紧密地放在一起。
我的经验是，它可以帮助您快速获得概念validation版本，但可以引入您可能不熟悉的重构要求（至少尚未。）
除此之外，该工具正在不断发展，最佳实践和模式尚未建立，也没有让其他程序员（或未来程序员）对您的代码感到满意的一致意见。 因此，我希望看到一段时间内的重构要求高于平常。
我会保持（乐观地）判断它在主流方面的定位。 此时我不会打赌当前的项目。 我处理阻抗不匹配的模式对我来说是令人满意的。
一旦你想做除最简单的选择，更新或删除之外的任何事情，你必须与ORM系统作斗争。 一旦你开始做真实的东西，你的表现就会进入厕所。
所以不行。
我期待着我的团队开始研究ORM解决方案的那一天。 直到那天，我们才是一个纯粹的DataSet / Stored Procedure商店，让我告诉你，并非所有的cookies和肉汁都是“纯净的”。
首先，新的Linq to SQL的性能接近于存储过程和数据读取器的性能。 我们在任何地方使用数据集，因此性能会提高。 到目前为止ORM非常好。
其次，存储过程具有单独发布代码的额外好处，但它们也不利于单独发布代码。 假装有一个数据库，其中有超过5个系统连接到它，超过10个人正在使用它。 现在考虑管理所有这些存储过程更改和依赖项，尤其是在存在公共代码库时。 这是一场噩梦……
第三，调试存储过程很困难。 由于各种原因，它们经常导致错误的行为。 这并不是说ORM生成的动态sql不会导致同样的问题，但少一个问题就是问题少一个。 没有权限问题（尽管大多数在SQL 2005中解决），没有更多的多步骤开发。 编写查询，测试查询，部署查询，将其绑定到代码中，测试代码，部署代码。 查询是代码的一部分，我认为这是一件好事。
第四，您仍然可以使用存储过程。 运行一些需要很长时间的报告？ 存储过程是更好的解决方案。 为什么？ 查询执行计划可以由数据库引擎优化。 我不会假装理解数据库的所有工作方式，但我知道当前优化动态sql存在一些限制，这是我们在使用ORM时所做的权衡。 但是，使用ORM解决方案时不会排除存储过程。
真的，我认为人们避免使用ORM的最大原因是他们根本没有经验。 将有一个明显的学习曲线和无知阶段。 但是，如果要提高开发性能并且几乎不会阻碍（或者在我的情况下改进）性能。 这是一个值得做出的折衷。
我也是使用EF和Linq-to-SQL的忠实粉丝。 我的理由是：
由于LINQ是编译的并且类型安全，因此您不会在“基于字符串的”SQL中遇到拼写错误的问题。 我不知道我花了多少时间追踪SP或其他SQL中的错误，其中“tick”或其他关键字位于错误的位置。
上述因素和其他因素使发展更快。
虽然与“更接近金属”的数据库查询方法相比，肯定存在开销，但如果性能成为我们的首要考虑因素，我们根本就不会使用.NET，甚至不会使用C ++。 对于大多数应用程序，我已经能够从Linq-To-SQL获得出色的性能，即使不使用存储过程方法（基于客户端的编译查询是我通常的方法）。
当然，对于某些应用程序，您仍然希望以旧式方式执行操作。
我想我的意思是，ORM使用传统的ADO.NET，SQL并将它们映射到代码中的对象来构建DAL的创新是什么？
以下是我的DAL的三个主要方面，我正在与ORM进行比较以了解其中的好处：
-
您仍然需要在ORM = SQL中进行查询（到目前为止SQL更强大）
-
映射代码移动到配置但仍未消除，只是从一个范例转移到另一个范例
-
对象必须与您的数据模式紧密相关地定义和管理，这与传统的方法不同，我可以将它们分离。
我错过了什么吗？
我一直非常密切关注Fluent-NHibernate，因为它有一些我在项目中见过的最有潜力。
我是一个很大的ORM人，从数据库中获取逻辑，仅使用数据库来提高速度。
我喜欢你开发应用程序的速度。 取决于ORM，最大的优势是您可以在不必翻译业务逻辑的情况下更改后端。
我切换到LINQ并且从未回头。 DBLinq对于使用除MSSQL之外的其他数据库非常棒。 我用它和MY SQL一起使用它很棒。
还没有，仍然持怀疑态度; 像大多数微软产品一样，我等待SP2或一年半之后再相信它们在产品环境中
并注意到几乎每个人都推出的新东西，不仅仅是微软，都被称为“轻巧，快速和简单” – 带上一块盐。 他们不会像利益/function那样大声宣传问题/问题！ 这就是我们等待早期采用者发现它们的原因。
这不是为了贬低ORM或LINQ或类似的东西; 直到，我才会保留判断力
- 我有时间评估它们，
- 有些需要只有他们才能满足，
- 该技术看起来稳定且受到良好支持，足以在我的客户的生产环境中冒险，和/或
- 客户要求它
请注意：我之前已经手动完成了ORM，它运行得很好，所以我对新的ORM系统寄予厚望。
如果codesmith根据您的表生成代码，您是否仍然与数据模式紧密耦合？ 我更喜欢一种解决方案，它将我的对象与我的数据库模式分离，以便在架构中实现灵活性
这是你的一条评论 – 这是真的，CodeSmith将你与你的桌子紧密地联系在一起。
另一方面，NHibernate有许多function可以帮助你：你有组件，所以在代码中你可以拥有：具有属性地址的人，其中地址是一个单独的类。
你还inheritance映射 。 因此，它可以很好地将您的架构与您的域解耦。
在我工作的地方，我们仍然使用手工卷制，重复切割’D’Paste DAL。 它非常痛苦，复杂且容易出错，但它是所有开发人员都能理解的。 虽然它目前对我们有用，但我不推荐它，因为它开始在大型项目上迅速崩溃。 如果有人不想进行全面的ORM，我至少会提倡某种DAL生成。
我正在努力在.NET中编写一个ORM工具作为一个让我受理的副项目。
SQL对我来说是死的。 我讨厌写它，特别是在我的代码中随处可见。 手动为每个对象编写select / insert / update / delete查询是浪费时间IMO。 在动态生成查询时，甚至不让我开始处理NULL（“where col_1 =？”vs“col_1 is null”）。 ORM工具可以为我处理。
此外，有一个地方可以动态生成SQL可能需要很长时间才能消除SQL注入攻击。
另一方面，我使用过Hibernate，我绝对讨厌它。 在一个真实的单词项目中，我们每隔几周就遇到限制，未实现的位和错误。
保持查询逻辑数据库端（通常作为视图或存储过程）也具有可供DBA调整的优点。 使用Hibernate，这是我上一份工作的一场持续战斗。 DBA：“给我们所有可能的查询，以便我们可以调整”Devs：“呃，我不知道，因为Hibernate会动态生成它们。我可以给你一些HQL和XML映射！” DBA：“不要让我打你的脸！”
我不喜欢大多数ORM中使用的代码生成。 实际上，一般来说，代码生成我发现它是一个弱工具，通常表示首先使用错误的语言。
特别是.Netreflection，我认为不需要代码生成用于ORM目的。
这是一个强烈的意见 。
不，我倾倒了ORM并转而使用了一个小屁股和一个OODB：Gemstone。 更好的代码，更少的代码，更快的开发。