c# - 存储库模式 - 使其可测试、DI 和 IoC 友好且 IDisposable

标签 c# unit-testing inversion-of-control repository-pattern idisposable

我有什么:

public interface IRepository
{
   IDisposable CreateConnection();
   User GetUser();
   //other methods, doesnt matter
}

public class Repository
{
   private SqlConnection _connection;

   IDisposable CreateConnection()
   {
      _connection = new SqlConnection();
      _connection.Open();
      return _connection;
   }

   User GetUser()
   {
      //using _connection gets User from Database
      //assumes _connection is not null and open
   }
   //other methods, doesnt matter 
}

这使得使用 IRepository 的类易于测试并且 IoC 容器友好。但是,使用此类的人必须在调用任何从数据库获取内容的方法之前调用 CreateConnection,否则将抛出异常。这本身有点好——我们不希望在应用程序中有持久的连接。所以使用这个类我是这样做的。

using(_repository.CreateConnection())
{
    var user = _repository.GetUser();
    //do something with user
}

不幸的是,这不是很好的解决方案,因为使用此类的人(甚至包括我!)经常忘记在调用方法从数据库获取内容之前调用 _repository.CreateConnection()

为了解决这个问题,我查看了 Mark Seemann 博客文章 SUT Double他以正确的方式实现了存储库模式。不幸的是,他让 Repository 实现了 IDisposable,这意味着我不能简单地通过 IoC 和 DI 将它注入(inject)类并在之后使用它,因为在一次使用之后它就会被处理掉。他在每个请求中使用它一次,并在请求处理完成后使用 ASP.NET WebApi 功能来处理它。这是我无法做到的,因为我的类实例一直在使用存储库。

这里最好的解决方案是什么?我应该使用某种可以给我 IDisposable IRepository 的工厂吗?那么它会很容易测试吗?

最佳答案

您的设计中存在一些问题点。首先,您的IRepository 接口(interface)实现了多级抽象。创建用户是比连接管理更高层次的概念。通过将这些行为放在一起,您正在打破 Single Responsibility Principle这表明一个类(class)应该只有一个责任,一个改变的理由。您还违反了 Interface Segregation Principle这将我们推向狭窄的角色界面。

最重要的是,CreateConnection() 和 GetUser 方法是时间耦合的。 Temporal Coupling是一种代码味道,您已经看到这是一个问题,因为您可以忘记对 CreateConnection 的调用。

除此之外,您将开始在系统中的每个存储库上看到连接的创建,并且每个业务逻辑都需要创建连接或从外部获取现有连接。从长远来看,这变得无法维护。然而,连接管理是一个横切关注点;您不希望业务逻辑关注如此低级别的问题。

您应该首先将 IRepository 拆分为两个不同的接口(interface):

public interface IRepository
{
    User GetUser();
}

public interface IConnectionFactory
{
    IDisposable CreateConnection();
}

您可以在更高级别管理事务,而不是让业务逻辑本身管理连接。这可能是请求,但这可能过于粗糙。您需要的是在表示层代码和业务层代码之间的某处开始事务,但不必自己复制。换句话说,您希望能够透明地应用这个横切关注点,而不必一遍又一遍地编写它。

这是我开始使用所描述的应用程序设计的众多原因之一 here几年前,业务操作是使用消息对象定义的,其相应的业务逻辑隐藏在通用接口(interface)之后。应用这些模式后,您将有一个非常清晰的拦截点,您可以在其中启动事务及其对应的连接,并让整个业务操作在同一个事务中运行。例如,您可以使用以下通用代码,这些代码可应用于应用程序中的每个业务逻辑:

public class TransactionCommandHandlerDecorator<TCommand> : ICommandHandler<TCommand>
{
    private readonly ICommandHandler<TCommand> decorated;    
    public TransactionCommandHandlerDecorator(ICommandHandler<TCommand> decorated) {
        this.decorated = decorated;
    }

    public void Handle(TCommand command) {
        using (var scope = new TransactionScope()) {
            this.decorated.Handle(command);
            scope.Complete();
        }
    }   
}

此代码将所有内容都包裹在 TransactionScope 中。这允许您的存储库简单地打开和关闭连接;这个包装器将确保仍然使用相同的连接。通过这种方式,您可以将 IConnectionFactory 抽象注入(inject)到您的存储库中,并让存储库在其方法调用结束时直接关闭连接,而在幕后,.NET 将保持真正的连接打开。

关于c# - 存储库模式 - 使其可测试、DI 和 IoC 友好且 IDisposable,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40114559/

相关文章:

c# - 如何从基类的实例初始化派生类的实例?

c# - 关于在C#中删除字符串

java - 模拟final类及其抛出异常的方法

android - 将触摸发送到 ActivityInstrumentationTestCase2 测试时如何修复 INJECT_EVENTS 权限异常

C# - Ninject、IoC 和工厂模式

c# - 抽象单例背后的 IoC 容器——做错了吗?

c# - 我应该使用 BlobContainerClient 还是 BlobClient 还是两者都使用?

c# - WebMethod 未被调用。 ASP.NET C#

unit-testing - 使用 Jest 和 Enzyme 测试 switch 语句

c# - Ninject 从 IBinding 获取目标类型