领域设计之模型充血、Repository对象注入

　　工作中接触了不少项目组，他们在实际的项目开发中，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的注入。当然，你想用第三方依赖注入库也可以，不过不是必选的。（老婆叫吃饭，代码随便搞了下没细看，如有错误你们多包涵。）

原标题：领域设计之模型充血、Repository对象注入

关键词：