这里的每个人都加入了ORM乐队吗?

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

ORM工具在其他平台上已经存在很长时间了,比如Java、Python等。现在以Microsoft为中心的团队发现了ORM工具,这似乎是一种新的时尚。总的来说,我认为这是一件好事——这是探索和理解体系结构和设计概念的过程中必不可少的一步,这些概念似乎是随着.NET的到来而引入的。

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

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

我是一个巨大的ORM倡导者。使用ORM生成代码可以为我们的大多数项目节省20-30%的成本。

Chris Lively提出了一个有趣的观点,即在任何时候碰到查询时都必须进行重新部署。这对某些人来说可能是个问题,但它根本不会影响我们。我们有规则禁止直接更改生产数据库。

但这并不是说他们解决了所有问题。它是一种工具,可以在有意义的地方使用。如果您的数据库模式与您的业务对象需要的模式相对接近,那么ORMs是最好的。

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

ORM是一个老问题,多年前由物镜和Top Link等产品解决。物镜是ParkPlace在90年代建造的一种小型ORM。Top Link由Object People为Smalltalk构建,然后转换为Java,目前由Oracle使用。Top Link也从90年代开始出现。DDD的倡导者现在开始清楚地阐明DDD的理由,并获得大家的认同。因此,ORM必然会成为主流,而微软只是照常做出反应。

这是大多数ORM工具(尤其是LINQ到SQL:

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

例如,“我的日常工作”当前可以通过修改现有存储过程并重新部署该存储过程来解决大多数查询问题。使用Linq等,您的数据查询将移动到实际代码中。猜猜那是什么意思?

ORM非常适合那些与为他们编写软件的软件相处融洽的人;但是,如果您对控制发生了什么以及为什么要这样做非常着迷,那么ORM可能是次优的,尤其是在数据库优化方面。任何抽象层都有成本和收益;ORM两者都有,但平衡还不正确。具有讽刺意味的是,ORM在其当前形式中添加了一个抽象层,它仍然将类和未经验证的数据库模式紧密地结合在一起。

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

除此之外,该工具还在不断发展,最佳实践和模式还没有很好地建立起来,也没有让其他程序员(或未来的程序员)对您的代码感到满意的共识。因此,我希望在一段时间内看到比通常更高的重构要求。

我将保留(乐观地)关于主流化的判断。在这一点上,我不会拿当前的项目打赌。我处理阻抗失配的模式符合我的目的。

一旦你想做最简单的选择、更新或删除之外的事情,你就必须与ORM系统抗争。一旦你开始做真正的事情,你的表演就会进入厕所。

所以没有。

我期待着我的团队开始研究ORM解决方案的那一天。直到那天,我们还是一家纯粹的数据集/存储过程商店,让我告诉你,并不是所有的饼干和肉汁都是“纯粹的”。

第二,存储的进程具有单独发布代码的额外好处,但也有单独发布代码的缺点。假设您有一个数据库,其中有5个以上的系统连接到该数据库,并且有10多人在处理该数据库。现在考虑管理所有这些存储过程更改和依赖项,特别是在有公共代码库的情况下。这是一场噩梦。。。

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

实际上,我看到人们避免使用ORM的最大原因是他们根本没有使用ORM的经验。将有一个明显的学习曲线和无知阶段。然而,如果它要提高开发性能,并且几乎不妨碍(或者在我的情况下提高)性能。这是一个值得做的权衡。

我也是一个超级粉丝,使用EF和Linq来编写SQL。我的理由是:

因为LINQ是编译的并且是类型安全的,所以在“基于字符串的”SQL中不会出现打字错误的问题。我不知道我花了多少时间跟踪SP或其他SQL中的错误,其中“勾号”或其他关键字出现在错误的位置。

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

虽然与数据库查询的“接近金属”方法相比,当然有开销,但是我们中没有人会使用.NET,或者甚至C++如果性能是我们关注的1。对于 即使不使用存储过程方法(基于客户端的编译查询是我常用的方法),我也能够从Linq到SQL获得优异的性能。

当然,对于某些应用程序,您仍然希望以老式的方式进行操作。

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

1. 您仍然必须在ORM=SQL中有一个查询(到目前为止,SQL更强大)

3. 对象必须与您的数据模式紧密相关地定义和管理,这与传统方法不同,我可以将它们解耦。

我一直在密切关注Fluent NHibernate,因为它是我在项目中见过的最有潜力的。

我是一个喜欢ORM的人,从数据库中获取逻辑,使用数据库只是为了提高速度。

我喜欢你开发应用程序的速度。根据ORM的不同,最大的优势是您可以更改后端,而无需转换业务逻辑。

我换了林克,再也没有回头。 DBLinq 对于MSSQL以外的其他数据库来说,这是非常棒的。我已经将它与我的SQL一起使用,它非常棒。

请注意,几乎所有人(不仅仅是微软)介绍的每一件新事物都被誉为“轻量级、快速和简单”——对此不屑一顾。他们不会像宣传优点/功能那样大声宣传问题/问题!这就是我们等待早期采用者发现它们的原因。

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

• 我有时间对他们进行评估,
• 该技术看起来稳定且支持良好,足以在我的一个客户的生产环境中承担风险,和/或
• 客户请求它

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

这是你的一条评论——没错,CodeSmith把你紧紧地绑在桌子上。

另一方面,NHibernate有一些特性可以帮助实现这一点:您有组件,这样在代码中您可以有:Person和属性地址,其中Address是一个单独的类。

你也 inheritance mapping . 因此,它在将模式与域分离方面做得相当好。

在我工作的地方,我们仍然使用手工轧制的、重复剪切的“n”粘贴。这是非常痛苦、复杂和容易出错的,但这是所有开发人员都能理解的。虽然它目前正在为我们工作,但我不推荐它,因为它开始在大型项目中迅速崩溃。如果有人不想进入全面的ORM,我至少会提倡某种DAL生成。

事实上,我正致力于在.NET中编写一个ORM工具,作为一个辅助项目,让我保持娱乐。

SQL对我来说已经死了。我讨厌写它,尤其是在我的代码中的任何地方。在我看来,为每个对象手动编写select/insert/update/delete查询是一种浪费时间的行为。在动态生成查询时,甚至不要让我开始处理null(“where col_1=?”vs“where col_1为null”)。ORM工具可以帮我解决这个问题。

此外,拥有一个可以动态生成SQL的位置,有望在消除SQL注入攻击方面取得很大进展。

另一方面,我使用了Hibernate,我非常讨厌它。在一个真实的word项目中,我们每隔几周就会遇到限制、未实现的位和bug。

保留查询逻辑DB端(通常作为视图或存储过程)还有一个好处,即DBA可以进行调优。在我上一份工作中,使用Hibernate是一场持续不断的战斗。DBA:“给我们所有可能的查询,这样我们就可以调整”Devs:“呃,我不知道,因为Hibernate会动态生成它们。不过我可以给你一些HQL和XML映射!”DBA:“别让我打你的脸!”

特别是对于.Net反射,我认为不需要为ORM目的使用代码生成器。

这是 one strong opinion .