为什么要用pojo？

如果你考虑到用对象POJO封装数据，然后再辅助以POJO行为来保证POJO内部数据的完整性，那么就有必要使用POJO。请参考DDD领域模型。

否则，就直接使用MAP。

相反，只有Setter/getter的贫血模型POJO反而会阻碍系统的维护，多此一举。

使用POJO对象是为了能够更加易于理解业务，也就是业务模型用POJO实现后，容易理解，易于维护，相对于Map一堆数据而言，Map是适合计算机系统，而POJO适合不懂计算机的业务专家。两种不同面向，Map这种数据方式正如数据表适合计算机系统一样。如果你是强人，看着一大堆Map数据能够看得懂其中业务逻辑，也是未尝不可，不是有大量业务逻辑用存储过程实现吗？一样的道理。

如果从软件工程角度来看，那么对象方法更通用
[该贴被banq于2013-07-01 16:03修改过]

还有两个问题POJO和Map在性能上差别大不大？
如果用Map做为POJO中的数据的容器，POJO中同样封装行为和规则，兼顾数据的完整性和灵活性可行不可行？

换句话是，这个概念的产生本质上就是荒谬的。我之前读《重构》时，非常欣赏Martin Fowler，现在我觉得他更多是炒概念和名词。

从面向对象的精神实质上来讲，一个类，应该有什么方法，由其业务层面的定义出发来分析的。举个例子，例如Admin这样一个类，自然拥有修改自身口令的方法 changePassword，不管你什么POJO还是EJB，还是Spring里的Bean，什么充血模型、贫血模型。

所谓“数据对象”这个词，实际上是从技术的观念和实现方法，给上推到设计领域的，这种“上推”不是很好的一种路子，设计应该不被实现技术所绑架，应该是从业务领域去分析。

我相信，不管设计开发的方法论发展到了什么时候，都需要从事物（或者系统，或者产品）的本质出发，来分析、设计、实现。

[该贴被windshome于2013-07-02 15:51修改过]

说得非常好，我很赞同。

如果楼主理解了这段话，你的疑问：
用Map做为POJO中的数据的容器，POJO中同样封装行为和规则，兼顾数据的完整性和灵活性可行不可行？

这实际是将用数据结构Map绑架业务对象，真正的应该是业务对象决定数据结构。
为什么这么说？如果你和不懂计算机专业的业务专家，比如财务专家，市场人士谈这个是一个Map，他不会明白什么是MAP，除非让所有人都读一下计算机专业。

[该贴被banq于2013-07-02 16:44修改过]

另外，POJO还是Map都是技术实现的范畴内的吧，它们和分析设计领域好像没啥关系， 毕竟我们既不会和业务专家讲POJO也不会讲Map.

这段时间要做个项目，有许多问题向大家请教!

我们讨论没有偏题，只是楼主没有认识到问题严重性而已。

POJO不属于技术范畴，因为POJO也是一个Object，而Object在英语中不属于技术专业术语，日常用语经常涉及，如同我们汉语中“事物”一样。

我们的系统要实现业务专家的需求，也就是产品经理的要求，你要和产品经理交流，你不能和产品经理用技术术语，而你使用“订单” “发票” “商品”这些Object用语，产品经理肯定能懂，你们能用一种统一语言交流，否则你说这用一个MAP实现，产品经理一头雾水，而你说这用一个订单对象(POJO)表达，产品经理应该能明白。

软件是实现需求的，比如需求是电子商务系统，如果在你的软件中找不到订单这个POJO，而是置于MAP之下，这实际是技术绑架业务，那么需求和软件之间就存在一个鸿沟：

需求中订单 ---> MAP数据结构
而如下：
需求中订单 ---> 订单POJO
是不是很直接？软件代码和需求严格直观一对一，中间不需要任何翻译？

直接一对一的软件更易于维护拓展，不管哪个程序员维护拓展都比较轻松，这实际软件工程，而不是软件手工作坊。

data User name age = MAP([("name",name),("age",age)])
getOlder :: Int -> [User]
getOlder old = f(old)...

在业务模型像计算机模型的映射过程中，尽量直接，不要在中间夹杂太多的解释。

今天结合DDD聚合思考：

把数据放在一个集合里，如Collection或Map，其实有两种可能性，第一种是用户希望看到这组数据，我们用集合打包一下；还有一种可能，业务领域中就存在这样一个集合，集合中包含这类数据，可能拥有共同的特征或行为或其他一致性，也就是同一性，可以归纳的，那么这个集合实际就是DDD中的聚合含义。