一个关于实体对象和值对象的困惑

现状：
我们现在有一个管理商家的系统，有一个商家的实体类Busi，一个商家注册方式的实体类Addmode。同时分别对应2张表。
Busi多对一关联Addmode。Addmode只有一个非主键属性type，属性值也相对固定，在数据表中只有2条记录——网站注册/代理商注册。

这种情况在我们系统中还有几个地方存在：比如投诉实体类，投诉类型实体类。

当时采用这种方式的目的是因为我们的系统有一个后台管理模块，这些类型是可以在这个管理模块进行维护的，增删操作。然后前台页面就会自动数据库中取到新的值，方便日后的维护。

困惑：
我们是采用hibernate作持久层的，我现在觉得为了一个非常简单的基本固定的属性，我们要维护有一个类、一个hbmxml文件、一个DAO接口、一个DAO实现类、一个Service接口、一个Service类，而仅仅是为了在后台可以对它进行增删，这样的成本太高了。

最近看了一些值类型的文档，感觉这个Addmode应该是属于值类型，但是又不知道怎么重构到现有项目，并且满足后台自动增删操作。

各位专家有什么好的建议？

评论

28 楼 timshaw9791 2009-09-19  

。。。。hbmxml文件你手写么？DAO接口你还每类一个么？service接口把它拆分，基本上你这几个类就是CRUD，
只要自动生成hbmxml就行了，service，dao都共用，
是不是值对象，不是你这样来界定的，一个对象可以一会儿是值对象一会儿是实体对象。

非要找一个理由让你们心安理得的话，我建议一个：
一致性："所有的实体类我们都是这样搞的，这几个我们也不打算例外"，这样团队成员不会犯错。

最后，建议lz注意不时改进生成工具。

jeffen2006 写道

现状：

当时采用这种方式的目的是因为我们的系统有一个后台管理模块，这些类型是可以在这个管理模块进行维护的，增删操作。然后前台页面就会自动数据库中取到新的值，方便日后的维护。

困惑：
我们是采用hibernate作持久层的，我现在觉得为了一个非常简单的基本固定的属性，我们要维护有一个类、一个hbmxml文件、一个DAO接口、一个DAO实现类、一个Service接口、一个Service类，而仅仅是为了在后台可以对它进行增删，这样的成本太高了。

最近看了一些值类型的文档，感觉这个Addmode应该是属于值类型，但是又不知道怎么重构到现有项目，并且满足后台自动增删操作。

各位专家有什么好的建议？

27 楼 lonelybug 2009-09-18  

当你在设计的时候一直不断的围绕着数据库表来思考的话，你基本上完成不了DDD的设计上的任何优势。或者更确切地说，连面向对象的程度都难了。

26 楼 gavin.zheng 2009-05-25  

alter table Busi add (xtype smallint);
BusiSerice2 extends BusiSerice
好像在怎么做都有那么麻烦.

25 楼 tiankang 2009-05-20  

tibetjungle 写道

jeffen2006 写道

现状：
我们现在有一个管理商家的系统，有一个商家的实体类Busi，一个商家注册方式的实体类Addmode。同时分别对应2张表。
Busi多对一关联Addmode。Addmode只有一个非主键属性type，属性值也相对固定，在数据表中只有2条记录——网站注册/代理商注册。

这种情况在我们系统中还有几个地方存在：比如投诉实体类，投诉类型实体类。

当时采用这种方式的目的是因为我们的系统有一个后台管理模块，这些类型是可以在这个管理模块进行维护的，增删操作。然后前台页面就会自动数据库中取到新的值，方便日后的维护。

困惑：
我们是采用hibernate作持久层的，我现在觉得为了一个非常简单的基本固定的属性，我们要维护有一个类、一个hbmxml文件、一个DAO接口、一个DAO实现类、一个Service接口、一个Service类，而仅仅是为了在后台可以对它进行增删，这样的成本太高了。

最近看了一些值类型的文档，感觉这个Addmode应该是属于值类型，但是又不知道怎么重构到现有项目，并且满足后台自动增删操作。

各位专家有什么好的建议？

感觉楼主不是对值对象和实体对象的产生了困惑，而是对这样简单的CRUD操作，需要维护hbm.xml、dao、daoimpl、service、serviceimpl这么多的东西感到困惑。个人觉得这是过度设计了，而且是为了使用Hibernante而使用hibernate，为了迎合针对接口编程的概念而使用接口。像这么简单的功能，个人觉得完全用一个dao（可以用jdbc直接搞定，烦得去配hibernate或者ibatis），一个service直接实现就得了（或者service都不用，因为用service的话，service估计也只是一个delegate），以后如果需要维护更复杂的东西，再想办法重构。毕竟程序这东西，做出来总是要随着业务的变化不停修改的，而且重构活动是开发过程很重要的一个活动。

楼上说的对的，楼主如果为了使用hibernate而故意去迎合它的话，那么将来受累的就是你自己。一些实体，一些描述这些实体的值对象，你要怎么管理它们才能获得更高的可扩展性，可维护性，可以重用性？而不至于掉入到hibernate的设计陷阱中。

24 楼 tibetjungle 2009-05-16  

jeffen2006 写道

现状：
我们现在有一个管理商家的系统，有一个商家的实体类Busi，一个商家注册方式的实体类Addmode。同时分别对应2张表。
Busi多对一关联Addmode。Addmode只有一个非主键属性type，属性值也相对固定，在数据表中只有2条记录——网站注册/代理商注册。

这种情况在我们系统中还有几个地方存在：比如投诉实体类，投诉类型实体类。

当时采用这种方式的目的是因为我们的系统有一个后台管理模块，这些类型是可以在这个管理模块进行维护的，增删操作。然后前台页面就会自动数据库中取到新的值，方便日后的维护。

困惑：
我们是采用hibernate作持久层的，我现在觉得为了一个非常简单的基本固定的属性，我们要维护有一个类、一个hbmxml文件、一个DAO接口、一个DAO实现类、一个Service接口、一个Service类，而仅仅是为了在后台可以对它进行增删，这样的成本太高了。

最近看了一些值类型的文档，感觉这个Addmode应该是属于值类型，但是又不知道怎么重构到现有项目，并且满足后台自动增删操作。

各位专家有什么好的建议？

感觉楼主不是对值对象和实体对象的产生了困惑，而是对这样简单的CRUD操作，需要维护hbm.xml、dao、daoimpl、service、serviceimpl这么多的东西感到困惑。个人觉得这是过度设计了，而且是为了使用Hibernante而使用hibernate，为了迎合针对接口编程的概念而使用接口。像这么简单的功能，个人觉得完全用一个dao（可以用jdbc直接搞定，烦得去配hibernate或者ibatis），一个service直接实现就得了（或者service都不用，因为用service的话，service估计也只是一个delegate），以后如果需要维护更复杂的东西，再想办法重构。毕竟程序这东西，做出来总是要随着业务的变化不停修改的，而且重构活动是开发过程很重要的一个活动。

23 楼 jasstion 2009-05-12  

本人现在还在自学，不过说一下自己的见解，诸位专家不要见笑。
你可以在其他的Service类中实现你想要的操作么，然后在其他的Action类中加上增加或删除操作么，不过这个Action类应该继承DispatchAction类，并且请求参数设置成Method，另外字段很少你没有必要为其建立ActionForm啦直接获取请求参数，再不行的话你就不要映射啦直接用原始的SQL语句，由于那个表设计的操作字段很少么也不是太复杂！

22 楼 yiding_he 2009-05-10  

你想把它持久化的话，多的是地方。写到配置文件里面都行。

21 楼 nihongye 2009-05-10  

当然没有必要建立AddModuleService,XXType...只因一个原则，不要重复的代码。
只因有多个具体实现的时候接口才有存在的必要，同样的道理，dao，如果不是复用的需要，也不必存在。你所说的模块结构是一个足够灵活，但对大多数情况却无比臃肿的结构。

20 楼 cats_tiger 2009-05-10  

有一个叫做jconfig的小东西可以解决你的问题。它支持xml，Database等方式实现对各种“类别、职称、性别、学历...”的管理。

19 楼 y_franky 2009-05-10  

Addmode 用枚举代替，在你的场景内 Addmode 基本上是不变的，要变的话，程序的流程都需要改，你根本不需要把 Addmode 搞成实体。

18 楼 hatedance 2009-05-10  

我觉得为一/多个简单的基础表配上一整套dao,service是合理的。
显得整个架构很容易理解，排列整齐。

这个做起来可能觉得很枯燥，没价值。

但如果选择将service，dao合并，问题也不大。写文档告诉维护的人就行了。

17 楼 maceaykk 2009-05-09  

这样一个小东西，还用得着持久层，自己写两个类处理下就可以了，其实这种小项目不必非要使用软件工程和软件模型中的那一套，基本上这种项目所设计的代码重用性不高

16 楼 kjj 2009-05-09  

找你说的那么简单的话，会不会是设计出问题了，疑惑你没有理解人家设计的思想所在！

15 楼 fansofjava 2009-05-09  

如果要问关于DDD的东西，最好还是换个地方吧

14 楼 pcwang 2009-05-09  

如果这些类属性相近或相同，可以合并成一个类吗？
最多加一个type字段区分是做什么的，这样只需要一个dao一个service，可以满足了吧？

13 楼 crabboy 2009-05-09  

值对象的一个特征是：没有独立的主键，必须依赖于某个实体对象

12 楼 sslaowan 2009-05-09  

泛型DAO，然后有一个方法叫setEntity，把你的值对象放进去，然后就可以CRUD了

11 楼 sulong.wang 2009-05-09  

楼主既然选择了这种模式，最好还是和其它领域对象保存相同的处理方式，不要因为其内容少而觉得浪费。Groovy+Grails默认优于配置的方式也许会和你的胃口，你愿意的Business Object照样可以使用。

10 楼 whaosoft 2009-05-09  

呃 我怎么感觉上面所有人的回答和楼主想知道的都不对路呢

9 楼 leeo 2009-05-09  

Addmode只有一个非主键属性type？这个表没有主键？
我的意思是：这个表中现在虽然只有两条记录，数量少一点，但是这个表的地位一点都不低；而且随着业务的发展，很有可能出现第三条、第四条。。。记录

将注册来源方式放到一个单独的表中是明智的，确实是有利于后期维护；

既然注册方式只涉及到了增删改查，并没有其他相关的业务逻辑，按照以上各位大虾的说法，确实没有必要使用service，直接操作Dao和DaoImpl就可以了；