|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-04-27
我个人原来的想法是如果是内存操作, 而又是domain对象相关的我放在domain里面, 如果要访问持久层之类的话就放在service里面, 保证domain只是个纯粹的模型. 可以供客户端直接操作, 我也没用hibernate lazy loading之类的, 因为我比较喜欢有独立层次. 但现在我还没机会自己去试试其他的方案.
|
| 返回顶楼 | |
|
发表时间：2004-04-29
Quake Wang 写道 但是我看到稍微复杂一些逻辑的代码, 比如User加入某个Group, 用
User.joinGroup(Group group);
还是用
UserService.addUserToGroup(User user, Group group);
这个是否值得讨论? 或许仅仅是语义上的区别? 前者是User自发的加入某个Group的行为, 而后者是管理员添加User加入Group行为? 我也在为这样的问题而犯愁，不过单从你举的例子来看，更多的情况下是管理员会添加User到Group中去。不过有时候我还是选择把一些业务逻辑放到Domain Object里面的，至于如何界定我想没有一个标准，一般可能是让Client如果调用的方便一点吧 btw:本来我也是想产生万能的上帝对象和只有数据的DomainObject |
| 返回顶楼 | |
|
发表时间：2004-04-29
Quake Wang 写道 对于getGroup(), getUser()这些简单的get reference方法我都是写在Domain Object, 我想不会有人写成UserService.getGroup(User user) 这样来用吧? 但是我看到稍微复杂一些逻辑的代码, 比如User加入某个Group, 用
User.joinGroup(Group group);
还是用
UserService.addUserToGroup(User user, Group group);
这个是否值得讨论? 或许仅仅是语义上的区别? 前者是User自发的加入某个Group的行为, 而后者是管理员添加User加入Group行为? 这我现在用user.setGroup()呵呵， 自从用了hibernate，就这样了 或者group.setUsers(list)。 如果哪天hibernate能够不局限于set,get，就好了。 user属于哪个group，并不是由管理员确定的。而是固有的。 例如老刘和老张都是处长，那么他们就都属于处长group，而不是管理员任命他们当处长。 引用 你误解我的想法了, 这些行为应该是一个Visit obejct (系统访问对象), 所拥有的, 比如login是AnonymousVisit的行为, 而logout就是NamedVisit的行为. 这招不错，学了一招~ 好 引用 另外CRUD这些方法我还是写在Service对象里面. 我现在为了减少service中的方法，把service分为crud四种。 然后不用dao，改用command模式。因为用了hibernate后，dao重复性非常大。 哪怕是用baseDao也是重复的太多。改用findByIdCommand, deleteCommand等等 引用 感觉这些业务代码应该在Domain Object和Service之间应该有一个分布原则, 不知道大家的实践是怎么样的. 我现在是按照potian说的，删除，创建，检索写在service里面，关系写入domain |
| 返回顶楼 | |
