这样的话不知道他们怎么处理群集？看来这次EJB3从Hibernate中吸取了很多东西，使得Application Server的灵活性得到了进一步的加强。

这里面有一个POJO概念的转换，原来Hiberante提出的POJO，只是Model 的POJO，是一种数据的POJO。

更重要的是，而随着Ioc模式的诞生，Service性质的POJO得到重视，可注射可配置的普通JavaBeans可以扩展到整个组件。

所以，这两种性质的POJO是不一样的，因为其蕴含的意义很不一样，后者是Spring/PicoContainer推动的重要变革。

Transparent and automated persistence
Your application server’s CMP engine implements automated persistence. It takes care of the tedious details of JDBC ResultSet and PreparedStatement handling. So does Hibernate; indeed, Hibernate is a great deal more sophisticated in this respect. But Hibernate does this in a way that is transparent to your domain model.
We use transparent to mean a complete separation of concerns between the persistent classes of the domain model and the persistence logic itself, where the persistent classes are unaware of―and have no dependency to―the persistence
mechanism.

Mapping persistent classes
Our Item class, for example, will not have any code-level dependency to any Hibernate API. Furthermore:
1、
Hibernate doesn’t require that any special superclasses or interfaces be inherited or implemented by persistent classes. Nor are any special classes used to implement properties or associations. Thus, transparent persistence improves code readability, as you’ll soon see.
2、
Persistent classes may be reused outside the context of persistence, in unit tests or in the user interface (UI) tier, for example. Testability is a basic requirement for applications with rich domain models.
3、
In a system with transparent persistence, objects aren’t aware of the underlying
data store; they need not even be aware that they are being persisted or retrieved. Persistence concerns are externalized to a generic persistence manager
interface ―in the case of Hibernate, the Session and Query interfaces.
Hibernate的这几点，正是EJB值得借鉴的地方，EJB的规范太复杂了。

框架是银弹吗？

今天在TSS看到一个老外Paul发言，他指责框架是银弹，意译：
所有这些框架都是银弹，很显然他们中没有一个会强大得充足或者持久（兔子尾巴长不了），讽刺的是：虽然他们号称减少复杂性，但是实际是相反（我以前从来不需要所有这些XML文件，复杂的ID和ORM工具)，

有趣的是，在EJB突然出现以前，你并没有听到很多关于好的设计的讨论，开发者似乎被这些架构许偌的美景迷住了，无论如何，一旦你需要帮助时，你得迈出他们的盒子box，你迷失了。 这些天所有我听到是新语言,IDE工具，好像可以使编码简单。

不就是显示和数据层分离吗？这并不难，使用Jsp/Servlet/JDBC也可以实现，只是人们并没有很好地去设计，是设计问题，也没有工具来纠正这些设计问题。


All these frameworks seem like silver bullets and this is evidenced by the fact that none of them seem to have much staying power. The ironic thing is that instead of decreasing accidental complexity, they seem to increase it. (I never needed all these XML files, complex IDEs, and ORM tools before) It's funny that you don't hear much discussion about good design anymore ever since EJB's popped up. Developers seemed to be enamored with the paint-by-numbers approach towards design that these architectures seem to promise. However, once you have to step outside of their box you find that rather than helping you, they get in your way. All I seem to hear about nowadays are new languages, IDE's, tools, etc that are supposed to make coding easier. What happened to good design? It's amazing that a whole sub-industry has popped up to just replace the layer that places data in an HTML page and the layer that gets data from the database. It's not that hard. You're moving a value from one place to another. It doesn't require a new paradigm or a tool set beyond JSP's, Servlets, and JDBC. These are simple tools that do the job and they're appropriately simple for the simple problem they solve. I've found they only suck when people can't design properly, but no tool is going to fix that.


我的评论：最难的是最后一句：没有任何工具或框架来改正人们错误的设计，那么只有在编码之前，使用可配置性的框架来指导人们编程，引导他们走向正确的设计方向。就象为防止小树长歪，需要用杆子绑定扶持一样。

当然，逼迫使用框架的人就有满腹抱怨了，配置麻烦，所以，好的框架是既能达到引导好的设计目的，也要易于使用的优点。