发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 3 下一页 Go 3

为什么要用pojo?

                   
2013-07-01 15:21
赞助商链接

我是JAVA的的一个菜鸟,一直让我困惑的是为什么要把数据放到一个POJO类中,为啥不用一个map代替?
数据交换用JSON,内部用Map, 系统是不是比用POJO简单多了?

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

4
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修改过]

2013-07-01 17:17

谢谢banq的解答!
是不是可以这样理解:
1。只有getter/setter的POJO可以用map代替。
2。如果POJO中封装了行为和业务规则的用POJO好。
3。POJO静态的定义了数据结构,容易理解,但也限制了系统的灵活性。

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

2013-07-02 15:42

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

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

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

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

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





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

2013-07-02 16:09

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


说得非常好,我很赞同。

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

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

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

3Go 1 2 3 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com