我知道网上已经有很多关于此主题的帖子。
但是，很多人在谈论它时往往会关注不同的事情。我的主要目标是创建易于维护的可伸缩Web应用程序。开发和维护的速度远远超过原始性能（或者我可以使用Java）。
这是因为我注意到当项目的代码大小增加时，您必须具有可维护的代码。当我第一次以程序方式编写我的应用程序时，没有任何框架，它只在1个月后成为一场噩梦。我完全迷失在意大利面条代码行的丛林中。我根本没有任何结构，即使我为实施一个结构而奋斗。
然后我意识到我必须以正确的方式拥有结构和代码。我开始使用CodeIgniter。这真的给了我结构和可维护的代码。许多用户说框架正在减慢速度，但我认为他们错过了这个画面。代码必须易于维护且易于理解。
Framework + OOP + MVC使我的Web应用程序结构化，以便添加功能不再是问题。
当我创建模型时，我倾向于认为它代表了一个数据对象。也许是一个表格甚至一个表/数据库。所以我想到了ORM（学说）。也许这将是我的Web应用程序的另一个很棒的实现，它给了它更多的结构，所以我可以专注于功能而不是重复自己。
但是，我之前从未使用任何ORM，我只学习了它的基础知识，为什么它的使用效果很好等等。
所以现在我问你们所有像我一样的人都在努力寻找可维护的代码，并且知道ORM（doctrine）对于可维护的代码是必须的，就像framework + mvc + oop一样吗？
我想要比“原始sql更快”的建议更多的生活经验建议，因为如果我只关心原始性能，我应该首先放弃框架+ mvc + oop并且继续生活在编码噩梦中。< / p>
感觉它非常适合MVC框架，其中模型就是表格。
现在我在一个文件中有150个sql查询，可以通过id获取条目，按名称获取条目，通过电子邮件获取条目，通过X获取条目等等。我认为ORM可以减少这些行，否则我很确定将来会增长到1000 sql行。如果我改变一列，我必须改变所有这些！真是一场噩梦再次思考它。也许这也可以给我很好的模型，适合MVC模式。
ORM是获取结构和可维护代码的正确方法吗？
答案 0 :(得分：6)
Ajsie，
我的投票是针对ORM。我使用NHibernate。它并不完美，并且有一个相当大的学习曲线。但代码更易于维护，更多OOP。除非你喜欢大量的重复代码，否则几乎不可能在没有ORM的情况下使用OOP创建应用程序。它肯定会消除你的绝大部分SQL代码。
这是另一回事。如果您打算构建一个OOP系统，那么无论如何您最终都会编写自己的O / R Mapper。您需要调用动态SQL或存储过程，将数据作为读取器或数据集，将其转换为对象，将关系连接到其他对象，将对象修改转换为sql插入/更新等。您所写的将是比NHibernate更长，更多的马车，或者长期在市场上销售的东西。
您唯一的另一个选择是构建一个以数据为中心的程序性应用程序。是的，它可能在某些领域表现更快。我同意表现很重要。但最重要的是它的快速足够。如果你在这里和那里保存几毫秒的程序代码，你的用户将不会注意到性能的提高。但是你会注意到糟糕的代码。
ORM中最大的性能瓶颈是以预取和延迟加载对象的正确方式。这会导致ORM的n查询问题。但是，这些很容易解决。你只需要对你的对象查询进行性能调优，并限制对数据库的调用次数，告诉它何时使用连接等.NHibernate还支持丰富的缓存机制，因此你根本不会点击数据库。
我也不同意那些表示性能与用户有关并且维护是关于编码员的人。如果您的代码不易维护，那么添加功能将会出错并且速度很慢。您的用户会关心这一点。
我不会说每个应用程序都应该有一个ORM，但我认为大多数都会受益。另外，不要害怕在必要时偶尔使用带有ORM的本机SQL或存储过程。如果您必须对数百万条记录进行批量更新或编写非常复杂的报告（希望针对单独的非规范化报告数据库），那么直接SQL就是可行的方法。使用ORM进行OOP，事务，业务逻辑和C.R.U.D.东西，并使用SQL作为异常和边缘情况。
我建议在NHibernate和Onion Architecture上阅读Jeffrey Palermo的内容。另外，参加他的敏捷训练营或其他课程来学习O / R Mapping，NHibernate和OOP。这就是我们使用的：NHibernate，MVC，TDD，依赖注入。
答案 1 :(得分：5)
许多用户都说框架是 放慢速度，但我想他们 错过了大局。代码必须 可维护且易于使用 理解。
如果它的性能是Teh Suck，那么结构良好，高度可维护的系统就毫无价值！
可维护性对构建应用程序的编码人员有益。原始性能有益于将应用程序用于其工作（或其他）的真实人员。那么，他们的关注应该是最重要的：构建系统的人还是那些付钱的人？
我知道这并不是那么简单，因为客户最终会为结构不佳的系统买单 - 可能是更多的错误，肯定有更多的时间来修复它们，有更多的时间来实现应用程序的增强功能。通常情况下，一切都是权衡。
答案 2 :(得分：4)
我开始像你一样开发，没有orm工具。
然后我为软件开发更加工业化的公司工作，他们都使用某种orm映射工具（具有更多或更少的功能）。开发更容易，更快，生成更易维护的代码等。
但我也看到了这些工具的缺点：性能非常慢。但这主要是误用了该工具（在这种情况下是休眠）。
Orm工具是非常复杂的工具，因此很容易误用它们，但如果您有使用它们的经验，那么您应该能够获得与原始sql几乎相同的性能。我会给你三个建议：
编辑： Orm工具对于非常复杂的模型最有用：实体之间的许多关系。这是应用程序的配置部分或应用程序的复杂业务部分中遇到的大部分时间。 因此，如果您只有很少的实体，并且如果它们被更改（重构）的可能性更小，那么它就没用了。
少数实体和许多实体之间的限制尚不清楚。我想说50个不同的类型（sql表，没有连接表）很多，少于10个很少。
我不知道用于构建stackoverflow的是什么，但它必须经过非常仔细的性能测试。
如果您想构建一个负载量很大的网站，如果您没有这方面的经验，请尝试让您的团队中的某个人已经在这些网站上工作过（性能测试是真实的）数据集和具有代表性的并发用户数并不是一项简单快捷的任务。拥有经验的人将大大加快这一过程。
答案 3 :(得分：1)
保持高度的稳定非常重要。我开发了具有低级超高性能的大规模Web应用程序。最大的缺点是维护系统，即开发新功能。如果你慢慢开发，客户将寻找其他系统/应用程序..它的交易。如果你需要直接对sql进行optmized查询，大多数orms都有功能。 orm本身不是瓶颈。我会更多地谈论一个好的数据库设计。
答案 4 :(得分：0)
我想你错过了这张照片。每天为用户提供性能，他们完全不关心可维护性。你是种族中心主义者，你只关心你的个人关注，而不是那些支付系统费用的人。这不仅仅是为了您的便利。
也许您应该与用户坐下来观看他们使用您的系统一两天。那么你应该坐在一台与他们使用的PC（不是开发机器）相同功率的PC上，花一整个星期做什么，除了整天使用你的系统。那么你可能会理解他们的观点。