|
锁定老帖子 主题：一个关于实体对象和值对象的困惑
精华帖 (0) :: 良好帖 (0) :: 新手帖 (9) :: 隐藏帖 (3)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-10
有一个叫做jconfig的小东西可以解决你的问题。它支持xml，Database等方式实现对各种“类别、职称、性别、学历...”的管理。
|
| 返回顶楼 | |
|
发表时间：2009-05-10
当然没有必要建立AddModuleService,XXType...只因一个原则，不要重复的代码。
只因有多个具体实现的时候接口才有存在的必要，同样的道理，dao，如果不是复用的需要，也不必存在。你所说的模块结构是一个足够灵活，但对大多数情况却无比臃肿的结构。 |
| 返回顶楼 | |
|
发表时间：2009-05-10
你想把它持久化的话，多的是地方。写到配置文件里面都行。
|
| 返回顶楼 | |
|
发表时间：2009-05-12
本人现在还在自学，不过说一下自己的见解，诸位专家不要见笑。
你可以在其他的Service类中实现你想要的操作么，然后在其他的Action类中加上增加或删除操作么，不过这个Action类应该继承DispatchAction类，并且请求参数设置成Method，另外字段很少你没有必要为其建立ActionForm啦直接获取请求参数，再不行的话你就不要映射啦直接用原始的SQL语句，由于那个表设计的操作字段很少么也不是太复杂！ |
| 返回顶楼 | |
|
发表时间：2009-05-16
最后修改：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），以后如果需要维护更复杂的东西，再想办法重构。毕竟程序这东西，做出来总是要随着业务的变化不停修改的，而且重构活动是开发过程很重要的一个活动。 |
| 返回顶楼 | |
|
发表时间：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的设计陷阱中。 |
| 返回顶楼 | |
|
发表时间：2009-05-25
alter table Busi add (xtype smallint);
BusiSerice2 extends BusiSerice 好像在怎么做都有那么麻烦. |
| 返回顶楼 | |
|
发表时间：2009-09-18
当你在设计的时候一直不断的围绕着数据库表来思考的话，你基本上完成不了DDD的设计上的任何优势。或者更确切地说，连面向对象的程度都难了。
|
| 返回顶楼 | |
|
发表时间：2009-09-19
。。。。hbmxml文件你手写么？DAO接口你还每类一个么？service接口把它拆分，基本上你这几个类就是CRUD，
只要自动生成hbmxml就行了，service，dao都共用， 是不是值对象，不是你这样来界定的，一个对象可以一会儿是值对象一会儿是实体对象。 非要找一个理由让你们心安理得的话，我建议一个： 一致性："所有的实体类我们都是这样搞的，这几个我们也不打算例外"，这样团队成员不会犯错。 最后，建议lz注意不时改进生成工具。 jeffen2006 写道 现状：
当时采用这种方式的目的是因为我们的系统有一个后台管理模块，这些类型是可以在这个管理模块进行维护的，增删操作。然后前台页面就会自动数据库中取到新的值，方便日后的维护。 困惑： 我们是采用hibernate作持久层的，我现在觉得为了一个非常简单的基本固定的属性，我们要维护有一个类、一个hbmxml文件、一个DAO接口、一个DAO实现类、一个Service接口、一个Service类，而仅仅是为了在后台可以对它进行增删，这样的成本太高了。 最近看了一些值类型的文档，感觉这个Addmode应该是属于值类型，但是又不知道怎么重构到现有项目，并且满足后台自动增删操作。 各位专家有什么好的建议？ |
| 返回顶楼 | |
