asp.net-mvc-3 - 如何减少对 Controller 的注入(inject)依赖项的数量

Question

我正在使用 MVC3、Entity Framework v4.3 Code First 和 SimpleInjector。我有几个看起来像这样的简单类:

public class SomeThing
{
    public int Id { get; set; }
    public string Name { get; set; }
}

我有另一个看起来像这样的实体:

public class MainClass
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual AThing AThingy { get; set; }
    public virtual BThing BThingy { get; set; }
    public virtual CThing CThingy { get; set; }
    public virtual DThing DThingy { get; set; }
    public virtual EThing EThingy { get; set; }
}

每个 Thingy(当前)都有自己的 Manager 类，如下所示:

public class SomeThingManager
{
    private readonly IMyRepository<SomeThing> MyRepository;

    public SomeThingManager(IMyRepository<SomeThing> myRepository)
    {
        MyRepository = myRepository;
    }
} 

因此，我的 MainController 如下:

public class MainController
{
    private readonly IMainManager MainManager;
    private readonly IAThingManager AThingManager;
    private readonly IBThingManager BThingManager;
    private readonly ICThingManager CThingManager;
    private readonly IDThingManager DThingManager;
    private readonly IEThingManager EThingManager;

    public MainController(IMainManager mainManager, IAThingManager aThingManager, IBThingManager bThingManager, ICThingManager cThingManager, IDThingManager dThingManager, IEThingManager eThingManager)
    {
        MainManager = mainManager;
        AThingManager = aThingManager;
        BThingManager = bThingManager;
        CThingManager = cThingManager;
        DThingManager = dThingManager;
        EThingManager = eThingManager;
    }

    ...various ActionMethods...
}

实际上，这个 Controller 中注入(inject)的依赖项是原来的两倍。它闻起来臭臭的。当您还知道存在具有所有或大部分相同依赖项的 OtherController 时，气味会更糟。我想重构它。

我已经对 DI 有足够的了解，知道属性注入(inject)和服务定位器不是好主意。

我无法拆分我的 MainController，因为它是一个单一的屏幕，需要通过单击一个保存按钮来显示和编辑所有这些内容。换句话说，单个 post 操作方法可以保存所有内容(尽管我愿意更改它，只要它仍然是单个 Save 按钮)。这个屏幕是用 Knockoutjs 构建的，如果有影响的话，它会用 Ajax 帖子保存。

我幽默地使用了环境上下文，但我并不肯定这是正确的方法。
我也幽默地使用了注入(inject) Facade。
我也想知道我是否应该在这一点上实现一个命令架构。
(以上所有内容不只是将气味转移到其他地方吗？)

最后，也许独立于上述三种方法，我是否应该使用一个具有显式方法的 LookupManager，例如 GetAThings()、GetAThing(id)、GetBThings()、GetBThing(id) 等？ (但是那个 LookupManager 需要注入(inject)几个存储库，或者一种新型的存储库。)

除了我的想法之外，我的问题是，重申一下:重构此代码以减少注入(inject)依赖项的疯狂数量的好方法是什么？

Answer 1

使用 command architecture是个好主意，因为这会将所有业务逻辑移出 Controller ，并允许您添加 cross-cutting concerns无需更改代码。但是，这并不能解决您的 constructor over-injection 问题。 .标准解决方案是将相关依赖项移至 aggregate service .但是，我同意马克的观点，您应该看看 unit of work pattern .