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

Command和DCI之间有一个对比。 在Command中，您可以分配对象之间的交互，而在DCI中，您可以通过角色方法来集中交互。 在MoneyTRansfer示例中，由于帐户是简单数据，没有任何行为，因此帐户将无法提取或存款。 但是，在诸如Transfer之类的上下文中，角色将存在行为。 因此，当源帐户角色绑定到帐户对象时，该帐户对象将具有提款行为，而目标帐户也是如此。

在命令模式中，它们具有行为，但是行为的执行在命令对象中编写了脚本，并且可以传递。 整个交互不是命令对象的一部分，而是通常分布在参与对象之间。

在马文（Marvin）中，由于大多数现代语言仅部分支持DCI，因此该语言构建为支持DCI，因此您只能将角色绑定到构造函数中的对象。 调用构造函数的方式与上下文无关。 这样可以确保对所有角色都进行一次绑定。 这样，重新绑定只能通过实例化另一个上下文来实现。 这不是DCI的限制，而是Marvin的设计选择。

关于上下文方法是否可以接受参数的问题，这有点哲学，但是据我记得上次我与Trygve Reenskaug辩论时，我们同意他们可以接受参数，并且我知道我已经实现了一些实例（包括DCI站点的汇款）。