在复杂的服务层为国际奥委会的最佳实践 [英] Best practices for IoC in complex service layer

问题描述

我开发一个MVC应用程序，我使用的是统一政府间海洋学委员会。我的应用程序基本上由一个UI层，服务层和存储库层。

I'm developing an MVC application, I'm using Unity for IoC. My Application basically consists of a UI layer, a services layer and a repository layer.

我的典型控制器是：

public class TestController : Controller
    {
        private ITestService testServ;

        public TestController(ITestService _testServ)
        {
            testServ= _testServ;
        }

    public ActionResult Index()
    {
        testServ.DoSomething();
        return View();
    }
}

没有什么与众不同，我的每个控制器有一个服务对象注入。所以，我的服务层对象进行复杂的业务规则汇集来自许多不同的资料库信息。通过使用IoC的我发现我的构造看上去过于复杂，但作为服务需要访问很多版本库，我看不到解决这个办法。

Nothing out of the ordinary, each of my controllers has a service object injected. So of my service layer objects carry out complex business rules aggregating information from many different repositories. By using IoC I'm finding my constructors look overly complex, but as the service requires access to many repositories I cannot see any way around this.

在我的业务层一个典型的类看起来像：

A typical class in my service layer will look like:

public class TestService : ITestService
    {
        private ITransactionRepository transRepo;
        private IAccountRepository accountRepo;
        private ISystemsRepository sysRepo;
        private IScheduleRepository schRepo;
        private IProfileRepository profileRepo;

        public TestService(ITransactionRepository _transRepo;
                           IAccountRepository _accountRepo;
                           ISystemsRepository _sysRepo;
                           IScheduleRepository _schRepo;
                           IProfileRepository _profileRepo)
        {
            transRepo = _transRepo;
            accountRepo = _accountRepo;
            sysRepo = _sysRepo;
            schRepo = _schRepo;
            profileRepo = _profileRepo;
        }

        public DoSomething()
        {
            //Implement Business Logix
        }
    }

我的几个服务层对象需要10个或更多的存储库。我坐在库使用实体框架，每个库类暴露在底层数据存储的表。

Several of my service layer object require 10 or more repositories. My repository sits is using Entity Framework where each repository class exposes a table in the underlying data store.

我正在寻找像描述的情况最佳做法的一些建议。

I'm looking for some advice on best practice in a situation like described.

推荐答案

下面是一些步骤简化（和减少）的依赖关系：

Here are some steps to simplify (and decrease) dependencies:

1. 拆分您服务到不同的服务，并在控制器中注入他们。这会降低服务的依赖数量。缺点是，你需要注入更多的依赖于你的控制器。下一步骤是分割控制器，当他们变得复杂。记得单一职责原则。

看看界上下文的模式：你可以尝试组实体往往走到一起在单个上下文中，注入这方面成为一个服务，而不是注入几十库的：

Take a look at Bounded Context pattern: you could try to group entities that often comes together in single context and inject that context into a service instead of injecting tens of repositories:

public class TestService : ITestService
{
    private readonly ITestData testData; // represents a bounded context

    public TestService(ITestData testData)
    {
        this.testData = testData;
    }

    public void DoSomething()
    {
        this.testData.Transactions.Add(...); //It gives you access to Transactions repository
    }
}

这篇关于在复杂的服务层为国际奥委会的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！