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

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

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

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

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

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

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

他是不是值对象跟你的增删改查有什么关系？

一个对象是实体还是值对象要看其所处的业务的位置。一个对象可能在一个业务中就是实体，是一个独一无二的存在，但是在另外一个业务中就是值对象。大家可以随意使用丢弃，因为值对象是不可变的。
具体情况要结合你的实际业务进行具体分析，在此无法给你太详细的建议，建议看看《领域驱动设计》中关于这两者的描述，希望对你有所帮助。

我的问题是怎么设计这类问题，我的实际业务也描述的应该比较清楚了，概念性的东西我也看过。希望实践家来解决！

那看来是我没仔细读你的话。你认为处理代价太高。我觉得主要是你架构设计的问题。对象类本身和XML配置是必须的。然后Dao和Service是否要呢？我觉得使用一个通用Dao就可以了。你们也应该有这么一个Dao作为其他具体Dao对象的父类。你直接调这个Dao就是了。而且Service里没有任何业务，不需要存在。你这种没有任何业务，只是纯粹的仓储操作，直接调用Dao就可以了。不用僵化的单独写接口写类。

如果是项目的话
增删改操作用同一个dao.....
同一个sverice
类要有多个....
在hibernate 可以自已识别object的类名与table名

从我们的业务看，商家注册方式Addmode，无疑是一个值对象，但我们又要后台维护这个值对象的属性。

为了简单（不要将之复杂成实体对象），只能采用非hibernate的方式了；或者将所有整个系统的此类值类型通过一个通用的实体对象统一通过hibernate解决。

失望，都没说到一个点上

一般表的字段是不会经常添加的。。

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

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

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