DCI:如何通过依赖注入实施上下文

Question

DCI上下文的大多数示例都是作为命令模式实现的。但是，当使用依赖项注入时，将依赖项注入构造函数并将参数发送到执行方法很有用。比较命令模式类：

public class SomeContext
{
    private readonly SomeRole _someRole;
    private readonly IRepository<User> _userRepository;
    // Everything goes into the constructor for a true encapsuled command.
    public SomeContext(SomeRole someRole, IRepository<User> userRepository)
    {
        _someRole = someRole;
        _userRepository = userRepository;
    }
    public void Execute()
    {
        _someRole.DoStuff(_userRepository);
    }
}

带有依赖项注入类：

public class SomeContext
{
    private readonly IRepository<User> _userRepository;
    // Only what can be injected using the DI provider.
    public SomeContext(IRepository<User> userRepository)
    {
        _userRepository = userRepository;
    }
    // Parameters from the executing method
    public void Execute(SomeRole someRole)
    {
        someRole.DoStuff(_userRepository);
    }
}

最后一个看起来好多了，但是我从未见过这样的实现，所以我很好奇是否有任何考虑。

Answer 1

命令和DCI之间存在对比度。在命令中，您可以在对象之间分布相互作用，在DCI中，您可以通过rolemethods集中交互。在MoneyTransfer示例中，帐户将无法撤回或存入，因为它们是没有行为的简单数据。但是，在诸如转移之类的上下文中，角色将存在行为。因此，当源帐户角色绑定到帐户对象时，帐户对象获取撤回行为，而目标帐户也是如此。

在命令模式中，他们具有行为，但行为的执行在命令对象中脚本脚本，可以通过。整个交互不是命令对象的一部分，而是在参与对象之间分布。

在马文（Marvin）中，由于意识到大多数现代语言仅部分支持DCI的意识到，一种支持DCI的语言构建，您只能将角色绑定到构造函数中的对象。您如何称呼构造函数不关心上下文。这样可以确保对所有角色进行一次绑定。然后，只有通过其他上下文的实例化才能重新固定。这不是DCI的约束，而是Marvin的设计选择。

关于上下文方法是否可以进行争论的问题，这有点哲学上实施了一些示例（包括在其中包括的DCI网站上的货币转移）。