为什么要用pojo?

13-07-01 henlaotu
我是JAVA的的一个菜鸟,一直让我困惑的是为什么要把数据放到一个POJO类中,为啥不用一个map代替?

数据交换用JSON,内部用Map, 系统是不是比用POJO简单多了?

是不是很多人初学者有这种想法? 那个大侠给扫个盲?

5
banq
2013-07-01 15:55
如果你使用Node.js + mongoDB(key-value NoSQL)这样的架构,实际就是REST + MAP

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

否则,就直接使用MAP。

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

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

如果从软件工程角度来看,那么对象方法更通用

[该贴被banq于2013-07-01 16:03修改过]

henlaotu
2013-07-01 17:17
谢谢banq的解答!

是不是可以这样理解:

1。只有getter/setter的POJO可以用map代替。

2。如果POJO中封装了行为和业务规则的用POJO好。

3。POJO静态的定义了数据结构,容易理解,但也限制了系统的灵活性。

还有两个问题POJO和Map在性能上差别大不大?

如果用Map做为POJO中的数据的容器,POJO中同样封装行为和规则,兼顾数据的完整性和灵活性可行不可行?

windshome
2013-07-02 15:42
说个个人的感受和不客气的话,感觉POJO这东西就相当于C语言的struct了,完全把面向对象这一个概念给糟蹋了。

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

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

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

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

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

banq
2013-07-02 16:09
2013-07-02 15:42 "@windshome

"的内容

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

说得非常好,我很赞同。

如果楼主理解了这段话,你的疑问:

用Map做为POJO中的数据的容器,POJO中同样封装行为和规则,兼顾数据的完整性和灵活性可行不可行?

这实际是将用数据结构Map绑架业务对象,真正的应该是业务对象决定数据结构。

为什么这么说?如果你和不懂计算机专业的业务专家,比如财务专家,市场人士谈这个是一个Map,他不会明白什么是MAP,除非让所有人都读一下计算机专业。

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

henlaotu
2013-07-03 17:34
虽然讨论的有点偏差,还是学到一些东西, 就是工作中要多思考少迷信。

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

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

banq
2013-07-03 21:06
2013-07-03 17:34 "@henlaotu

"的内容

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

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

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

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

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

需求中订单 ---> MAP数据结构

而如下:

需求中订单 ---> 订单POJO

是不是很直接?软件代码和需求严格直观一对一,中间不需要任何翻译?

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

px96004
2013-07-04 11:20
我感觉,要是都用MAP,程序员都蒙了。。。

windshome
2013-07-05 09:15
MAP也可以啊,但是MAP是实现层的事情,一定得有个“皮”,其实也就是封装的意思。

liyi237851708
2013-07-05 10:30
我也不懂领域模型,不过感觉光从技术层面说,用map也是一种悲剧啊,比如c中存在的DataTable,从结构上来说感觉是个装载数据的好东西,但是从代码阅读上就很有问题

比如做开发时,经常要做接口,如果没有一份完整的API文档,肯定是场悲剧,假设我写了这样一个方法

public List<Map<String,Object>> getResult(Map<String,Object> map);

你能理解这样的参数,这样的返回值到底是要干什么么?

cintana
2013-07-10 11:37
考虑下你要设计个给其他人用的接口,当然是用POJO更容易理解。

用Map估计过一段时间自己也都读不懂代码了

SpeedVan
2013-07-12 17:40
出现这种思想是好的,至少不会简单去迷信一样东西。POJO其实是一种另类的声明方式,他跟MAP的最大不同是,它有一个特殊的名字。而且JAVA不是声明式,很多东西使用MAP后只会带来可读问题。实际上我们期待使用MAP的情况如下:

data User name age = MAP([("name",name),("age",age)])

getOlder :: Int -> [User]

getOlder old = f(old)...

huntter
2013-09-16 17:42
2013-07-03 21:06 "@banq

"的内容

需求中订单 ---> MAP数据结构

而如下:

需求中订单 ---> 订单POJO

是不是很直接?软件代码和需求严格直观一对一,中间不需要任何翻译? ...

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

banq
2013-09-26 15:24
2013-07-01 15:21 "@henlaotu

"的内容

一直让我困惑的是为什么要把数据放到一个POJO类中,为啥不用一个map代替 ...

今天结合DDD聚合思考:

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

猜你喜欢