具有基于数据库值的动态连接字符串的存储库模式

Question

我一直在考虑更新现有代码库，以更好地遵循设计模式、原则、处理单元测试、分离关注点等。我对实现很多这些概念很陌生，所以我仍在做大量研究和尝试看看如何在当前代码库中实现它们。

目前每个业务实体都有自己的vb文件。该 vb 文件中包含该实体的实体、实体集合和实体 dalc 类。如果要对实体执行数据库操作，可以调用 Enity.Save、Entity.Delete 等。实体类上的这些方法将创建实体 dalc 对象，然后调用 Save、Delete 等方法在实体 dalc 对象上。然后，dalc 将通过处理低级内容的 SqlHelper 类调用 Save、Delete 等存储过程。

每个实体类都需要将一个 Location 对象传递给它的构造函数。该对象用于了解用户登录的数据库以及创建到数据库的适当连接字符串。数据库都具有相同的架构；它们只是具有不同的名称，并且可以存在于不同的 SQL 实例上。基本上每个客户端都有自己的数据库，并且 Location 对象会访问一个共享数据库，以根据存储在 cookie 中的客户端名称找出客户端需要连接的 SQL 实例。

我一直在寻找更多的模型/存储库/服务方法，但 Location 对象让我失望，特别是因为它也需要访问数据库以获取创建正确连接字符串所需的信息。存储库对象需要连接字符串，但我看到的所有示例都将其硬编码在类中。我认为存储库对象将需要接收 Location 对象的接口，但我不确定 MVC 项目是否会直接执行此操作或将其传递给服务对象并且他们会处理它。 Location 对象是在什么时候创建的，因为它也需要访问数据库才能创建连接字符串，它是如何创建的？

我也不清楚 MVC 项目将如何与服务和存储库层进行交互。似乎一切都应该通过服务对象运行，但是为了测试，您希望它们接受存储库的接口。这样做意味着 MVC 项目需要传入存储库对象，但似乎 MVC 项目不应该知道存储库对象。但是，如果您只是在执行基本的 CRUD，那么让 MVC 项目直接在存储库对象上调用这些方法而不是通过服务对象运行它们似乎会更简单。

这是我目前正在研究的一个示例。该计划是现在使用 ADO.NET 和 SQL Server，但将来可能会切换到 ORM 甚至不同的 SQL 后端。我希望模型/存储库/服务方法能够在未来轻松地进行这些更改，所以如果不能随意提供建议。

Project.Model

public class Person
{
    public int Id;
    public string Name;
}

Project.Repository

public class PersonRepository
{
    public Person FindById(int id)
    {
        // Connect to the database based on the Location's connection string
    }
}

Project.Service

public class PersonService
{
    private IPersonRepository _personRepository;

    // Should this even take in the repository object?
    public PersonService(IPersonRepository personRepository)
    {
        _personRepository = personRepository;
    }

    // Should the MVC project call this directly on the repository object?
    public Person FindById(int id)
    {
        return _personRepository.FindById(id);
    }
}

Project.MCV

// I think the Location object needs to come from here, as the client name is
// in the cookie. I'm not sure how the controllers should interact with the
// service and repository classes.

Answer 1

我赞同@Christian 的建议。使用 ORM 将大大简化您与底层数据存储的交互； NHibernate 是一个不错的选择。

但是，在您的示例中，与表示（又名 ASP.NET MVC 项目）中的数据层交互的常用方法是将服务作为控制器的依赖项注入。

有几种方法可以做到这一点，最简单、最直接的方法是 use a dependency injection framework (like Unity) 以按照您在控制器的构造函数中指定的方式实例化您的服务，

public class PersonController : Controller
{
     private readonly IPersonService personService;

     public PersonController(IPersonService personService)
     {
         this.personService = personService;
     }
}

另一种方法是implement your own ControllerFactory implementation 并根据需要注入所需的服务。还有很多工作，但如果你有时间，你可以学到很多关于 ASP.NET MVC 路由流程的整体流程和一些 DI 本身的知识。

在 DI 框架中，您（主要）将 interfaces 注册到 concrete classes 实现，基本上是说当需要 IPersonRepository 的实例时，使用PersonRepositoryImpl。有了这些注册规则，DI 框架将递归地实例化出现在类构造函数中的每个依赖项。*

换句话说，当您请求PersonController 的实例时，DI 框架将尝试创建PersonController 类型的实例；当它看到构造函数需要IPersonService 类型的参数时，它首先尝试根据相同的规则实例化一个。因此，该过程再次开始，直到所有依赖项都已解决并注入PersonController的构造函数，

resolve PersonController
  -> construct PersonController(IPersonService personService) 
    -> resolve IPersonService with PersonService
      -> construct PersonService(IPersonRepository personRepository)
        -> resolve IPersonRepository with PersonRepository
          -> construct PersonRepository() <- this one has no dependencies

并备份堆栈，直到返回 PersonController 的新实例。

*为此，您必须只有 一个 给定类的公共构造函数，其中每个参数都是需要解析的依赖项（您的示例确定了这一点）。如果依赖的类型没有在框架中注册，解析将失败。如果有多个公共构造函数，解析也会失败（没有确定的方法来确定使用哪一个），除非您注册应该使用哪个构造函数（通常使用属性，但这取决于到位的 DI 框架）。一些 DI 框架（如 Unity）可能允许您根本没有构造函数（默认为空的、无参数的构造函数），并将依赖项作为标记为依赖属性的公共属性。我建议 不要 使用此方法，因为它无法从使用者类了解该类需要哪些依赖项（不使用反射检查所有属性并查看哪些属性被标记为依赖项），这将反过来导致无数的NullReferenceExceptions。