0

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);
    }
}

最後のものは少し良いように見えますが、私はそれがこのように実装されているのを見たことがないので、考慮すべきことがあるかどうか興味があります。

4

1 に答える 1

2

コマンドとDCIの間には対照があります。コマンドでは、オブジェクト間の相互作用を分散し、DCIでは、ロールメソッドを介して相互作用を一元化します。MoneyTRansferの例では、アカウントは動作のない単純なデータであるため、引き出しや入金を行うことはできません。ただし、転送などのコンテキストでは、その動作はロールに存在します。したがって、ソースアカウントの役割がアカウントオブジェクトにバインドされている場合、アカウントオブジェクトは撤回動作を取得し、宛先アカウントについても同じことが言えます。

コマンドパターンでは動作がありますが、動作の実行はコマンドオブジェクトでスクリプト化されており、渡すことができます。インタラクション全体はコマンドオブジェクトの一部ではありませんが、通常は参加オブジェクト間で分散されます。

マーヴィンでは、ほとんどの現代言語がDCIを部分的にしかサポートしていないという認識の結果として、DCIをサポートする言語ビルドであり、コンストラクター内のオブジェクトにのみロールをバインドできます。コンストラクターをどのように呼び出すかは、コンテキストには関係ありません。これにより、すべてのロールに対してバインドが1回実行されます。その場合、再バインドは、別のコンテキストのインスタンス化によってのみ可能になります。これはDCIからの制約ではなく、Marvinの設計上の選択です。

コンテキストメソッドが引数を取ることができるかどうかについての質問に対しては、少し哲学的ですが、前回Trygve Reenskaugと議論したときのことを覚えている限り、引数を取ることができることに同意しました。それらが行う例（DCIサイトでの送金を含む）。

于 2012-10-29T11:21:34.290 に答える