ORMs are a thing of the past

coredump

FROM：http://codemonkeyism.com/orms/
ORMs are a thing of the past. Hold your anger! I always thought ORMs were the next best thing after sliced bread. I was so convinced about ORMs that I wrote some of them on my own in Ruby and Java – not very good, mind you – during the 90s. Later I switched to commercial ones and settled with Hibernate and JPA for many projects. But after years of usage and seeing developers on my teams work with Hibernate, I’m no longer sure it is a good thing.
Beware: This is a non-conformist post. I’m also one of the very few people who think JPA/Hibernate annotations are bad for your domain classes. Keep this in mind while reading further.
Problems with ORMsThey are a delusion. They help you getting up to speed fast and prevent you from writing noisy boiler code. Over time they will pose problems, those problems becoming bigger than the speed you’ve gained. The biggest two:

• ORMs are most problematic due to performance concerns. Many developers I’ve met never look into Hibernate SQL logs to see what queries are generated, and how many of them. Should they ever look in the SQL which is executed, their eyes will pop up. Mine did. Nearly.
  As Aldo wrote in “A Farewell to ORMs”
  

  Whether or not the magical plumbing is worthwhile depends largely on how often the abstraction breaks down. The ORM approach does so frequently. Yes, I can use an ORM and think at the object level in the common case, but whenever I need to do anything remotely complicated – optimising a query, say – I’m back in the land of tables and foreign keys. In the end, the structure of data is something fundamental that can’t be simplified or abstracted away. The ORM doesn’t resolve the impedance mismatch, it just postpones it.
  

• Leaky abstractions. You think the ORM works but it doesn’t. It throws exceptions to you. Lazy initialization exceptions in Hibernate popping up in the most unfortunate circumstances because you made wrong assumptions about sessions, scope and flow. These are hard to find and often harder to fix.

But these are not the main reasons for the phasing out of ORMs over the next years. Additionally ORMs may hinder future development and not be a safe investment because they lose their grip on enterprise development with the advent of NoSQL data stores. Polyglot persistencewill make it harder to store data via ORMs, as thouse would need to cross reference stores. This is all highly speculative, and could be countered by: “Well, SQL isn’t safe either”. But nevertheless it needs consideration.
Solutions without ORMsThe most common argument against the performance impact of ORMs is to use caching. Caching in Hibernate does reduce the number of queries indeed. But caching done in XML, JSON or HTML is often more efficient than object caching. And should you need object caching, other solutions beside ORMs exist which explicit caching of objects like ehCache or Terracott in Java.
What about less boiler plate code due to ORMs? Good DAOs with standard CRUD implementations help there. Just use Spring JDBC for databases. Or use Scala with closures instead of templates. A generic base dao will provide create, read, update and delete operations. With much less magic than the ORM does. And although others think that DAOs are dead, the fraction of persistence increases the need for DAO abstraction. The downside of managing relations yourself isn’t as large as ten years ago, with many web databases denormalized. Or with part of the data already in NoSQL document databases.
Think about ORMs the next time you start a project.

yuba

Annotations, 呵呵

XML, JSON or HTML, 呵呵

Spring JDBC, 呵呵

uniwg

简单的用ibatis， 封装了SQL查询。不过是在XML中写查询语句，然后用一个标记来表示SQL查询。在业务层的代码看到的只是这些标记，开可以有参数，但只能有一个这是缺点。

flyspirit

ORM的速度确实是个很大问题。

hoopoos

对各种各样的各个层面的技术来说，我提倡换个角度来看，不是分析每个技术的缺点，而是重点在发现每种技术的优点。一般来说，凡是能广泛应用的技术都不会有很大的缺点，与此同时却都有一些突出的优点。

因此，ORMs are a thing of the past，这个观点我是不同意的。这就好比我有一个大的工具箱，不管里面有多少工具，我只管放，因为你不知道什么时候，就能用的上，我不会随便扔掉任何一件工具，除非这玩艺根本就没用处。

mayabin

过不过时用事实来说话吧。
我在2个项目里用过Hibernate，缺点是性能；优点是用HQL，不用考虑SQL和后台数据库。

所以，我的观点是，适合你的项目就是好的。不适合的也别硬往里整。
这年头，有喜欢穿唐装的，也有喜欢穿西服的，个人喜好不同而已。