业务逻辑层设计的一个问题

假设有一个简单的通讯录系统，有两个Domain Object，User和Contact，即用户和联系人，一对多的关系，然后会有一个ContactManager吧，其中有add/get/getList/update/delete这些方法，我想请教的问题是，以上这些方法中，基本都要传入一个userId，比如add(Contact contact,Integer userId)（插入联系人所属的用户id），或者delete(Contact contact,Integer userId)（判断该联系人是否是这个用户所属的），若方法越来越多，这种方式是否可行？或者我这种思路本来就不正确？请指教

Contact里面加入和User的多对一关联，直接从Contact里面访问到User

user.addContact
user.deleteContact
...

那就是没有ContactManager了？然后Domain Object也不能用失血模型了，所有的contact操作方法要放到User里面吗？

如果在桌面应用中,要多个ContactManager类,可用于更新UI组件;
业务逻辑层要和数据层分开吧
楼主这样设计业务层,数据层跟业务层也差不多吧

我觉得楼主的问题是否可以考虑aop一下,单独有个方法来做针对user与contact的检查!

import java.util.*;
public class User{
  private int userId;
  private List contactList;
	
  public User(int userId){
    this.userId = userId;
    this.contactList = new ArrayList();
  }

  public void setUserId(int userId){
    this.userId=userId;
  }
	
  public int getUserId(){
    return this.userId;
  }
	
  public getContactList(){
    return this.contactList;
  }
	
  public addContact(Contact ct){
    this.contactList.add(ct);
  }
	
  public deleteContact(int delId){
    ...
  }
	
  public updateContact(Contact ct){
    ...
  }
}

至于要将数据入库的话，还是放在UserManager中调用UserDAO

看需求，这里的Contact是从属于User的，因此User就是Contact管理类。user.addContact 、user.deleteContact 即可。

如果相关Contact的需求较为复杂，有无关于User的统计或其他操作，象按定制条件检索联系人、按地域/教育程度/年龄段统计所有联系人等，这时为了平衡类的复杂度，可以用ContactManager封装这些操作。但基本概念上Contact还是从属于User的，addContact/deleteContact仍放在User里即可

并非每个domain object就一定需要一个DAO来负责持久化，在实际中可根据use case的情形将几个对象组装起来一起使用，然后通过主对象来访问其他的对象。在本例中，user和contact组装一起，然后由user访问是比较合适的。而且象hibernate这样的工具也支持保存整个对象图的功能。

若这样的话，是否可以舍去所有的Manager接口和类？UserManager接口中的register/login等方法，也可以放在User类中，然后在各个方法中调用相应的Dao方法？这是否是DO中的充血模型？