你的位置:首页 > ASP.net教程

[ASP.net教程]领域设计之模型充血、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的注入。当然,你想用第三方依赖注入库也可以,不过不是必选的。(老婆叫吃饭,代码随便搞了下没细看,如有错误你们多包涵。)