工作中接触了不少项目组，他们在实际的项目开发中，Domain Object的贫血模型设计，还是主要的应用的范式。原因在于，贫血模型模型设计中，把所有涉及持久化的业务逻辑，封装到了Domain Service层或Application Service层，这样的一揽子方案，消除了对某一业务逻辑究竟建在域服务层还是域模型层的争议，使分层简单化了，简单的分层也便于团队协作开发和测试。
当然，由此带来的问题也不少。
一、语义不清；
二、业务复杂易出现不良设计，导致业务重复实现、bug成堆；
三、事务性业务需求和多任务并发检查易出错；
四、需求增长、变化带来开发成本快速增长（这比较象面向过程编程了，比较反OO）
出现的这些问题不解释，相信做过几回项目的或多或少遇到过。
写了这些，其实可以看出来，潜意识中我是支持使用充血模型的。充血模型可以把业务逻辑做的很薄，完全的业务语义化。在Domain Object层构建CRUD和粒子化的面向Entity的语义实现。（手懒，其实是这个电脑没装IDE,大家可以看这个链接的例子：http://www.cnblogs.com/chenzhao/archive/2012/08/13/2636179.html）
但是使用充血模型还有两个基本问题需要解决，一个是业务逻辑分层（这个比较烦，时间充裕的时候再写个例子）；一个是Domain Object层的Repository注入。
看下Domain Object层的Repository注入，不说了，看代码：
//Domain Object层
public interface IRoot
{
int id { get; set; }
}
public interface IPersistence<T>
{
IReposity<T> Repository { get; set; }
}
public interface IReposity<T> : IDisposable
{
T Add(T model);
}
public class User : IRoot, IPersistence<User>
{
public int id
{
get;
set;
}
public string Name
{
get;
set;
}
public IReposity<User> Repository
{
get;
set;
}
public void Add()
{
Repository.Add(this);
}
}
//-----------------------
//Domain Service层
public class UserManageService
{
public static void AddUser(User user)
{
user.Persistence().Add();
}
}
public static class UserEx
{
public static User Persistence(this User user)
{
user.Repository = new Repository<User>();
return user;
}
}
//------------------------
//Domain Repository层
public class Repository<T> : IReposity<T>
where T : class,IRoot, new()
{
public T Add(T model)
{
return null;
}
public void Dispose()
{
}
}
//------------------------
这样就通过服务层，可以向Domain Object 完成Repository Object的注入。当然，你想用第三方依赖注入库也可以，不过不是必选的。（老婆叫吃饭，代码随便搞了下没细看，如有错误你们多包涵。）
原文：http://www.cnblogs.com/xiaoxiaoii/p/4722258.html