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

Question

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

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

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

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

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

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

项目.模型

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

项目.存储库

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

项目.服务

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 项目)与数据层交互的常用方法是将服务作为 Controller 的依赖项注入(inject)。

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

public class PersonController : Controller
{
     private readonly IPersonService personService;

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

另一种方法是implement your own ControllerFactory implementation并根据需要注入(inject)所需的服务。这需要做更多的工作，但如果您有时间，您可以了解 ASP.NET MVC 路由流的全部流程和一些 DI 本身。

在 DI 框架中，您(大部分)使用 具体类 实现注册接口(interface)，基本上就是说，当需要 IPersonRepository 实例时，使用 PersonRepositoryImpl 的新实例。有了这些注册规则，DI 框架将递归地实例化每个依赖项，因为它出现在类构造函数中。*

换句话说，当您请求PersonController 实例时，DI 框架将尝试创建PersonController 类型的实例；当它发现构造函数需要类型为 IPersonService 的参数时，它会首先尝试根据相同的规则实例化一个。因此，该过程再次开始，直到所有依赖项都已解析并注入(inject)到 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 实例。

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