为什么你们的实体对象中都只有数据结构而没有行为?

翟志军 发布于 2013/08/09 13:29
阅读 1K+
收藏 4

国内的java开源软件项目看过一些,但都发现里面的Entity都只有get和set。而将行为放到dao或者service层里。这样是行为与数据的分离。

既然,java是面向对象的语言,为什么要将Entity的数据与行为分离呢?


我这里说的Entity是指有业务意义的类,如Person, Employee。

Employee,有离职,请假等行为。


@宏哥   @中山野鬼   @崔钢

加载中
0
宏哥
宏哥

因为

1:关系

2:Java这个烂语言不支持灵活的数组

南湖船老大
南湖船老大
说话说不到点子上,尽扯没用的PHPer
0
翟志军
翟志军

引用来自“宏哥”的答案

因为

1:关系

2:Java这个烂语言不支持灵活的数组

谢谢@宏哥 能否说得再详细一些。
0
宏哥
宏哥

引用来自“陈真诚”的答案

引用来自“宏哥”的答案

因为

1:关系

2:Java这个烂语言不支持灵活的数组

谢谢@宏哥 能否说得再详细一些。

1:关系意味着行为不是独立发生的, 不是简单的单表CRUD 

2:烂语言不支持灵活的数组, 所以需要实体对象这种烂玩意

翟志军
翟志军
我知道对象之间会有关系,会有消息的传递,但,这又怎么样呢?和我面向对象有什么关系?面向对象是对现实世界的抽象与什么数据库的无关吧?
0
blindcat
blindcat
大家都这么写罢了,你也可以在实体类里写业务逻辑。没有什么必须的,怎么弄觉得舒服就行。
0
antipro
antipro

虽然没有邀请我,还请允许我发表一下自己的愚见:

我感觉多数Entity的建立都是为了和数据库中的表记录建立关联而设置的,并不是为了封装业务内容。

其次,Entity并不排斥业务内容,只是Java的很多框架都强调MVC的分层模型,所以才会有Service这类东西,也方便管理。

最后,Entity在后期的使用过程中,当然也可以扩展,例如直接修改,或者构造派生类等等,只是很多业务并没有达到这一的复杂度,也就没必要了。

0
翟志军
翟志军

引用来自“blindcat”的答案

大家都这么写罢了,你也可以在实体类里写业务逻辑。没有什么必须的,怎么弄觉得舒服就行。
意思是因为大家这么写,所以,大家才这么写?
0
duty
duty
这跟java无关。。这是框架。。
0
翟志军
翟志军

引用来自“breaking”的答案

这跟java无关。。这是框架。。
如果不用框架,很多人也就这么写。。。而且,我从那些培训视频中看到,国内的IT培训机构也都是这么教的
0
duty
duty

引用来自“陈真诚”的答案

引用来自“breaking”的答案

这跟java无关。。这是框架。。
如果不用框架,很多人也就这么写。。。而且,我从那些培训视频中看到,国内的IT培训机构也都是这么教的
习惯了,这样写的好处比较多吧
0
Jeky
Jeky

行不行?完全可以;但是好不好完全就是另一回事了。

第一,Java开发者水平层次不齐,而贫血模型相对更容易理解(数据+对数据的操作),这就造成了有的公司开发规范中就明确要求实体类中不能掺杂进业务逻辑。

第二,我见过一些公司是这样的:首先设计表结构,然后通过表结构自动生成实体类,如果表结构修改了,那么就重新生成实体类。对于这样的公司,把业务逻辑放入实体类中也是不合适的。

第三,如果一个实体上的业务非常复杂,那么就会导致这个实体类非常庞大。我见过所谓的富血模型里一个类几千行,最后被要求重构,保持原有业务结构,但是业务逻辑委托到其他类中去。这实际上是从富血模型到贫血模型的一种变相退化。

第四,如@宏哥 所言,许多业务并不能简单地归属给某个实体类。 

第五,这种设计可能会导致Dao层次和业务层次直接耦合在一起,不方便Mock测试。
咯咯鸡
咯咯鸡
返回顶部
顶部