跨多个服务访问通用功能

本文关键字：功能 访问 服务 | 更新日期: 2023-09-27 18:36:25

我目前正在构建一个应用程序，就目前而言，我为每个控制器提供单个服务（该服务处理控制器的业务逻辑）。 每个服务都有自己的数据库上下文。

我已经认识到多个服务需要执行相同的功能（从数据库中检索相同的数据列表并在返回它们之前对它们执行相同的逻辑）。 因此，理想情况下，我需要一种让服务访问通用功能的方法。

我的第一个想法是创建一个每个服务都可以使用的简单帮助程序类，其中包含将 dbcontext 作为参数之一的简单函数，以便函数可以执行数据库查询以及逻辑并返回结果。

这是个好主意吗？ 我是否会通过以这种方式构建代码而遇到问题，或者我应该采取更好、更健壮和可接受的方法？

跨多个服务访问通用功能

我想说你走在正确的轨道上，但更进一步，单一责任原则。 http://blog.codinghorror.com/curlys-law-do-one-thing/。这是保持代码干净的行之有效的策略。我避免每次说"助手"类。他们可能会因为承担太多责任而变得混乱。相反，我试着真正思考我的班级应该做什么。然后我给它起一个非常好的名字来提醒我，它只做那一件事。

每个服务都有自己的 Db 上下文这一事实可能是一个问题。只要确保在调用多个依赖服务时，在同一 Db 上下文中传递给它们。如果你的对象图很大，像AutoFac这样的容器将是一个很大的帮助。

返回的数据是否相同？它们是使用自己独特的数据库上下文还是相同的数据库上下文？

通常，我建议避免创建帮助程序类。通常，帮助程序类用于操作对象，而不是执行数据库查询。

根据您的评论，有两种方法可以实现这一点，一种比另一种更容易。

选项 1：

如果你的应用程序真的是一个简单的应用程序，你不太关心以"正确"的方式做事，那么你可以简单地创建基服务类并更新你的服务来扩展它，并将你的公共数据库访问移动到基类中，如下所示：

abstract class BaseService
{
    ...
    public ICollection<ExampleRecord> GetDatabaseRecords()
    {
        using (var context = new ApplicationDbContext())
        {
            /* Your DbContext code */
        }
        return databaseRecords;
     }       
    ...
}

然后像这样扩展BaseService：

public class ExampleService : BaseService
{
    ...
    public ICollection<ExampleRecord> GetRecords()
    {
        return this.GetDatabaseRecords();
    }
    ...
}

这样可以完成工作，并且是您当前正在做的事情的更好选择，但是这通常不是最佳方法。

选项2：

如果您的应用程序不仅仅是一个简单的应用程序，并且您担心代码可维护性，那么我建议您考虑将数据库访问代码移动到单独的存储库类中，并使用 IoC 容器（如 StructureMap）通过依赖注入将其所述存储库注入到您的服务中。

我个人会推荐选项 2，因为它更干净、更易于维护/可扩展，并且您没有违反任何 SOLID 原则。

您可以使用抽象服务来定义通用方法这是一个很好的教程通用存储库、服务层、IoC、单元测试实体框架

相关文章：