|
锁定老帖子 主题：DomainModel的持久化
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-02-02
domainModel的持久化以及从持久层的获取，这些工作属于谁的职责？
是应该置于model内部作为业务逻辑的一部分，还是由Service调用DAO来进行？ 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2005-02-02
drliujia 写道 domainModel的持久化以及从持久层的获取，这些工作属于谁的职责？
是应该置于model内部作为业务逻辑的一部分，还是由Service调用DAO来进行？ 是你的职责 |
| 返回顶楼 | |
|
发表时间：2005-02-02
我就是想搞清楚DomainMoel内是否需要DAO的支持？
|
| 返回顶楼 | |
|
发表时间：2005-02-02
领域模型的对象本身是不应该知道持久层实现甚至接口的，只需要维护模型对象之间的商业逻辑关系即可。
|
| 返回顶楼 | |
|
发表时间：2005-02-03
领域对象知道持久层的玩法就是"活动记录"模式，
模式没有对错，只有适用与否，所以选择怎样的玩法纯粹是自己的职责 |
| 返回顶楼 | |
|
发表时间：2005-02-03
Domain model里面只能有实体类？将对DAO的调用至于控制类中即可，实体类总是被动的。service－控制类－DAO都直接在Spring里面配置，而实体是他们之间传递的参数。
|
| 返回顶楼 | |
|
发表时间：2005-02-03
请参阅Martin Fowler的PoEAA，里面对于Domain Model的描述非常的清晰。
Domain Model指的是业务逻辑层，它需要从数据源层中获取相应的实体对象，这部可通过多种模式来实现，如DAO模式，如业务逻辑比较简单的情况下，实体对象即可充当Domain Model中的BO，如较为复杂，则需要构建相应的BO对象层，构成Domain Object，甚至需要引入Service层处理应用逻辑，引入工作流也可，^_^ |
| 返回顶楼 | |
|
发表时间：2005-02-03
muziq 写道 Domain model里面只能有实体类？将对DAO的调用至于控制类中即可，实体类总是被动的。service－控制类－DAO都直接在Spring里面配置，而实体是他们之间传递的参数。
这就是典型的事务脚本， 不是Domain model，真正的实体类必然是要直接或间接使用DAO的。 |
| 返回顶楼 | |
|
发表时间：2005-02-03
说得再直白一点，其实就是model对象里面是否应该出现对DAO的引用呢？
service层的工作是否要涉及model实例的load以及持久化？ |
| 返回顶楼 | |
|
发表时间：2005-02-03
|
| 返回顶楼 | |
