POJO产生的原因及目的?

如题.
使用POJO产生了什么样的好处?怎么觉得从模型里把方法剥夺了,看起来那么奇怪呢?

我看DDD建模里面的领域对象都是带方法的,怎么在JIVEJDON3里一实现就把方法放在service里了.这样做的好处是?

另外,剥夺出来的service和领域中真正的service放在一个包里?怎么觉得这么怪..

As a bonus, POJOs have these other important benefits:

Easier development—There is less cognitive load because rather than being forced to think about everything—business logic, persistence, transactions etc.—at once you can instead focus on one thing at a time. You can first design and implement the business logic and then, once that is working, you can deal with persistence and transactions.
Faster development—You can develop and test your business logic outside of the application server and without a database. You do not have to package your code and deploy it in the application. Also, you do not have to keep the database schema constantly in sync with the object model or spend time waiting for slow-running database tests to finish. Tests can run in a few seconds and development can happen at the speed of thought—or at least as fast as you can type!
Improved portability—You are not tied to a particular implementation technology. The cost of switching to the next generation of Java technology is minimized because you have to rewrite only a small amount of code, if any.

英文资料还是比中文的齐全哎?

查看本站资料,POJO是相对EJB2提出的概念,EJB2的问题是部署难,部署慢,POJO对EJB2有优势,但是EJB升级到EJB3,也是POJO后,POJO再和Domain Model靠拢,就有些牵强,所以,POJO概念火一段之后就没气了,不要去较真。

我看了<企业应用架构模式>后大致了解了pojo的提出原因,POJO不是一个技术,而是给一个旧有东西起的新名字,在j2ee早期,开发人员没有架构,自己封装业务自己处理安全和事务问题,这时候EJB产生了,人们看到了EJB让他们不再考虑事务和安全问题,然而真实使用EJB反而比过去自己处理事务和安全更麻烦。。。主要原因在于实体bean,所以在当时还没有轻量级架构情况下,MF等人大力反对使用只能运行在容器上的实体bean而用普通java对象,然而他纳闷为什么人们还在用实体bean?他总结“人们之所以不用普通java对象是因为普通java对象缺少一个响亮的名字”(企业应用架构模式原话),结果POJO这个名字产生了。

java对象宛如一个人,在10岁的时候是学生,所以他又“人”“学生”两个名字,25岁上班了,就多了“职员”这个名字,谁知道未来还会有哪些变革和改变,他还会增加哪些称号。。。