使用ORM还是纯SQL？
对于我开发的一些应用程序（后来忘记了），我一直在编写纯SQL，主要针对MySQL。 尽管我已经像PythonAlchemy一样在Python中使用了ORM，但我并没有坚持太久。 通常它是文档或复杂性（从我的角度来看）阻止我回来。
我看到它是这样的：使用ORM来实现可移植性，如果它只是使用一种类型的数据库，则使用纯SQL。 在开发需要数据库支持的应用程序时，我确实在寻找何时使用ORM或SQL的建议。
考虑一下，使用轻量级包装来处理数据库不一致与使用ORM相比，会好很多。
ORM具有一些很好的功能。 他们可以处理将数据库列复制到对象字段的大部分工作。 他们通常会将语言的日期和时间类型转换为适当的数据库类型。 它们通常通过实例化嵌套对象来优雅地处理一对多关系。 我发现，如果您在设计数据库时考虑到了ORM的长处和弱点，它可以节省数据进出数据库的大量工作。 （如果你需要映射它们，你会想知道它是如何处理多态和多对多的关系的，这两个域提供了大部分'阻抗不匹配'，这使得一些ORM成为'计算机科学的越南' 。）
对于具有事务性的应用程序，即您发出请求，获取一些对象，遍历它们以获取某些数据并将其呈现在网页上，性能税很小，并且在很多情况下，ORM可以更快，因为它会缓存对象以前看过，否则会多次查询数据库。
对于报表繁重的应用程序或每个请求处理大量数据库行的应用程序来说，ORM税负要重得多，并且他们所做的缓存变成了一个巨大的，无用的内存占用负担。 在这种情况下，精简DAL中的简单SQL映射（LinQ或iBatis）或手动编码的SQL查询是最好的选择。
我发现，对于任何大型应用程序，您都会发现自己使用这两种方法。 （用于报告的简单CRUD和SQL /精简DAL的ORM）。
作为一个花了很长时间处理JPA（Java持久性API，基本上是Java / J2EE / EJB的标准化ORM API）的人，包括Hibernate，EclipseLink，Toplink，OpenJPA和其他人，我会分享一些我的观察结果。
还有一个问题需要更多解释。
Web应用程序的传统模型是有一个持久层和一个表示层（可能有一个服务层或其他层，但这些是本次讨论的重要两层）。 ORM强制从持久层到表示层（即实体）的严格视图。
对更多原始SQL方法的批评之一是最终得到的所有这些VO（值对象）或DTO（数据传输对象）仅由一个查询使用。 这被吹捧为ORM的优势，因为你摆脱了这一点。
事情是那些问题不会与ORM一起消失，他们只是移动到表示层。 您可以创建自定义的演示文稿对象，而不是为查询创建VO / DTO，通常为每个视图创建一个。 这是如何更好？ 恕我直言，它不是。
我已经在ORM或SQL中写过关于这方面的内容：我们在那里吗？
我最近选择的Java持久性技术是ibatis。 这是一个非常简单的SQL封装，它可以完成JPA可以完成90％的工作（它甚至可以执行关系的延迟加载，尽管它没有很好的记录），但是开销（复杂性和实际代码）要少得多。
去年，我在写一个GWT应用程序。 从EclipseLink到服务实现中的表示对象有许多翻译。 如果我们使用ibatis，那么使用ibatis创建适当的对象然后将它们一直传递到堆栈上会非常简单。 一些纯粹主义者可能会认为这是Bad™。 也许如此（理论上），但我告诉你：它会导致更简单的代码，更简单的堆栈和更高的生产力。
我说Reads是简单的SQL，CUD是ORM。
性能是我一直关心的事情，特别是在Web应用程序中，还有代码可维护性和可读性。 为了解决这些问题，我写了SqlBuilder。
链接地址: http://www.djcxy.com/p/17193.html