|
锁定老帖子 主题：一个关于实体对象和值对象的困惑
精华帖 (0) :: 良好帖 (0) :: 新手帖 (9) :: 隐藏帖 (3)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-09
呃 我怎么感觉上面所有人的回答和楼主想知道的都不对路呢
|
| 返回顶楼 | |
|
发表时间：2009-05-09
楼主既然选择了这种模式，最好还是和其它领域对象保存相同的处理方式，不要因为其内容少而觉得浪费。Groovy+Grails默认优于配置的方式也许会和你的胃口，你愿意的Business Object照样可以使用。
|
| 返回顶楼 | |
|
发表时间：2009-05-09
泛型DAO，然后有一个方法叫setEntity，把你的值对象放进去，然后就可以CRUD了
|
| 返回顶楼 | |
|
发表时间：2009-05-09
值对象的一个特征是：没有独立的主键，必须依赖于某个实体对象
|
| 返回顶楼 | |
|
发表时间：2009-05-09
如果这些类属性相近或相同，可以合并成一个类吗？
最多加一个type字段区分是做什么的，这样只需要一个dao一个service，可以满足了吧？ |
| 返回顶楼 | |
|
发表时间：2009-05-09
如果要问关于DDD的东西，最好还是换个地方吧
|
| 返回顶楼 | |
|
发表时间：2009-05-09
找你说的那么简单的话，会不会是设计出问题了，疑惑你没有理解人家设计的思想所在！
|
| 返回顶楼 | |
|
发表时间：2009-05-09
这样一个小东西，还用得着持久层，自己写两个类处理下就可以了，其实这种小项目不必非要使用软件工程和软件模型中的那一套，基本上这种项目所设计的代码重用性不高
|
| 返回顶楼 | |
|
发表时间：2009-05-10
我觉得为一/多个简单的基础表配上一整套dao,service是合理的。
显得整个架构很容易理解，排列整齐。 这个做起来可能觉得很枯燥，没价值。 但如果选择将service，dao合并，问题也不大。写文档告诉维护的人就行了。 |
| 返回顶楼 | |
|
发表时间：2009-05-10
Addmode 用枚举代替，在你的场景内 Addmode 基本上是不变的，要变的话，程序的流程都需要改，你根本不需要把 Addmode 搞成实体。
|
| 返回顶楼 | |
