再次小结领域模型的种种观点

三、充血模型
充血模型和第二种模型差不多，所不同的就是如何划分业务逻辑，即认为，绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑)，而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和DAO层打交道。

public class CustomerServiceImpl implements CustomerService {
  public CustomerServiceImpl(); {}
  
  public void copyAndTweakCustomer(Integer id); {
    Customer original = dao.load(id);;
    
    Customer duplicate = new Customer();;
    duplicate.setId(original.getId(); + 1);;
    duplicate.setName(original.getName(););;
    
    original.setName("Michael Walls");;
    
    original.save();;
    duplicate.save();;
  }
  
  private CustomerDao dao;
  public void setDao(CustomerDao dao); {
      this.dao = dao;
  }
}

You'll notice that the service object is also injected with a CustomerDao. This is so that it can load a previously-persisted Customer. This illustrates an important point: Just because the domain object is now primarily responsible for its own persistence, that does not mean that service objects can't also access the DAO to load previously-persisted instances.

new Account(id);

我是比较同意robbin的观点的，举个登录的例子：

EmployeeService的实现：

    /* (non-Javadoc);
     * @see com.bearingpoint.gdc.service.EmployeeService#doLogin(java.lang.String, java.lang.String);
     */
    public Employee doLogin(String name, String password); throws ObjectNotFoundException, PasswordNotMatchException {
        Employee employee = null;
        List result = employeeDAO.getEmployeeByName(name);;
        if(result.size(); == 0);
            throw new ObjectNotFoundException();;
        else {
            employee = (Employee);result.get(0);;            
            if(!employee.getPassword();.equals(password););
                throw new PasswordNotMatchException();;
        }
        return employee;
    }

DAO的实现：

    /* (non-Javadoc);
     * @see com.bearingpoint.gdc.dao.EmployeeDAO#getEmployeeByName(java.lang.String);
     */
    public List getEmployeeByName(String name); {
        String querySentence = "FROM Employee employee WHERE employee.name = :name";
        Query query = getSession();.createQuery(querySentence);;
        query.setParameter("name", name);;
        return query.list();;
    }

Action更简单：

/* (non-Javadoc);
     * @see com.opensymphony.xwork.Action#execute();
     */
    public String execute(); throws Exception {        
        employee = employeeService.doLogin(employee.getName();, employee.getPassword(););;
        
        //put the employee into session
        ServletActionContext.getContext();.getSession();.put("currentEmployee", employee);;
        
        return SUCCESS;
    }

结构层次很清晰，DAO就负责数据库操作，Service层处理逻辑。万一你的业务逻辑发生扩展和变化，也只要修改和扩展你的Service实现，与其他层次无关。同时，Service层总是接受事务的控制。

按照firebody的观点，莫非我的doLogin的逻辑要写在我的Employee类里面？然后new Employee(String name, String password) throw xxxException？这太恶心了。

if(!employee.getPassword();.equals(password););
                throw new PasswordNotMatchException();; 

employee.authenticate(password);

Partech，看到这么一些代码：

public class AccountService {
           private AccountDAO dao;
           
           public void createAccount(Account ac);{
                     dao.save(ac);;
           }
            
            public void removeAccount(Account ac);{
                     dao.remove(ac);;
           }
          public void updateAccount(Account ac);{
                     dao.update(ac);;
           }
            
}

我不觉得它有多可爱，我横看竖看，前看后看，左看右看，上看下看，可还是看不出这个Service除了为获得事务外，他还做了什么东西。
如果他有一些逻辑方法里面包含一些有意义的业务逻辑，那我无话可说，但是我所看到很大一个比例的方法都是这样类似的delegate的代码。
很多人还喜欢先写Service的Interface ,再来写这些delegate代码，看着更是感到可爱。

你认为我的理解有什么不对吧？ 我很乐意你能够指出我的错误... 

public class AccountService{
      private IAccountRepository accountRepository;
      private IAccountInfoAssembler accountInfoAssembler;

      public AccountInfo getAccountInfo(String accountCode);{
                Account account = accountRepository.findByCode(accountCode);;
          return  accountInfoAssembler.create(account);;
     }
    
}

public class AccountService{
      private IAccountRepository accountRepository;
      private IAccountInfoAssembler accountInfoAssembler;

      public void createAccount(String Code,String Name,...);{
               IAct act = new CreateAccountAct(code,name,....);;
                act.run();;
     }
}

嗯，如果你的ServiceLayer接口里传递的参数包含DomainObject那么，ServiceLayer确实少了很多职责。
Service被看作Domain层和UI层的接口/外观，会具有适配两者的职责，通常我们不会把DomainObject直接传递到UI层，总是使用DTO,目前看看使用通用的SDO行不行，甚至异常也需要转换。如果使用Aspect来管理事务，Service里面的代码就很干净了。
对于查询操作：

public class AccountService{
      private IAccountRepository accountRepository;
      private IAccountInfoAssembler accountInfoAssembler;

      public getAccountInfo(String accountCode);{
                Account account = accountRepository.findByCode(accountCode);;
          return  accountInfoAssembler.Create(account);;
     }
    
}

对于更新操作：

public class AccountService{
      private IAccountRepository accountRepository;
      private IAccountInfoAssembler accountInfoAssembler;

      public createAccount(String Code,String Name,...);{
               IAct act = new CreateAccountAct(code,name,....);;
                act.run();;
     }
}

异常转换的处理和事务控制都可以通过Aspect达成。

Partech，看到这么一些代码：

public class AccountService {
           private AccountDAO dao;
           
           public void createAccount(Account ac);{
                     dao.save(ac);;
           }
            
            public void removeAccount(Account ac);{
                     dao.remove(ac);;
           }
          public void updateAccount(Account ac);{
                     dao.update(ac);;
           }
            
}

我不觉得它有多可爱，我横看竖看，前看后看，左看右看，上看下看，可还是看不出这个Service除了为获得事务外，他还做了什么东西。
如果他有一些逻辑方法里面包含一些有意义的业务逻辑，那我无话可说，但是我所看到很大一个比例的方法都是这样类似的delegate的代码。
很多人还喜欢先写Service的Interface ,再来写这些delegate代码，看着更是感到可爱。

你认为我的理解有什么不对吧？ 我很乐意你能够指出我的错误... 

public void addChild(Child c); {
    c.setParent(this);;
    children.add(c);;
}