9

私は MVC3 から始めて、いくつかの柔軟なアーキテクチャを使用したいので、何十ものブログや本 (Pro ASP.NET MVC 3) を読み、SOLID の原則について読み、最終的に気に入ったアプリケーション構造にたどり着きました (または少なくとも私はまだ何も構築していないので、これまでのところそうだと思います):

ここに画像の説明を入力

この構造では:

  • ドメインは POCO クラスを保持し、サービス インターフェイスを定義します
  • サービスはサービス インターフェイスを実装し、リポジトリ インターフェイスを定義します
  • データはリポジトリ インターフェイスを実装します
  • WebUI とドメイン利用サービス
  • サービスはリポジトリを使用します
  • WebUI、サービス、およびデータは、POCO クラスのドメインに依存します

サービスを使用するドメインの主な理由は、POCO (IValidatable) クラスの Validate メソッドで一意のキーを検証することです。

この構造の参照アプリケーションを作成し始めていますが、これまでのところ 2 つの問題に直面しています。

  1. リポジトリの単体テストを含む Data.Tests プロジェクトを使用していますが、サービスの実装を (コンストラクターまたはそれ以外で) モデルに (Ninject を使用して) 注入する方法が見つからないため、Validate メソッドでサービスで CheckUniqueKey を呼び出します。

  2. Ninject を TEST プロジェクトに接続する方法についてのリファレンスは見つかりませんでした (WebUI プロジェクトの場合はたくさんあります)。

ここで達成しようとしているのは、DATA アセンブリを変更するだけで、EF から DAPPER のような別のものに切り替えることができるということです。

アップデート

現在 (2011 年 8 月 9 日現在) Ninject は動作していますが、何か足りないと思います。

2 つのコンストラクターを持つ CustomerRepository があります。

public class CustomerRepository : BaseRepository<Customer>, ICustomerRepository
{
    // The repository usually receives a DbContext
    public CustomerRepository(RefAppContext context)
        : base(context)
    {
    }

    // If we don't receive a DbContext then we create the repository with a defaulte one
    public CustomerRepository()
        : base(RefApp.DbContext())
    {
    }

    ...
}

TestInitialize で:

// These are for testing the Repository against a test database

[TestInitialize()]
public void TestInitialize()
{
    // Context used for tests
    this.context = new RefAppContext();

    // This is just to make sure Ninject is working, 
    // would have used: repository = new CustomerRepository(context);

    this.kernel = NinjectMVC3.CreateKernel();

    this.kernel.Rebind<ICustomerRepository>().To<CustomerRepository>().WithConstructorArgument("context", context);

    this.repository = kernel.Get<ICustomerRepository>();

}

顧客クラス:

public class Customer : IValidatableObject 
{
    ...

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        // I want to replace this with a "magic" call to ninject
        CustomerRepository rep = new CustomerRepository();

        Customer customer = rep.GetDupReferenceCustomer(this);

        if (customer != null)
            yield return new ValidationResult("Customer \"" + customer.Name + "\" has the same reference, can't duplicate", new [] { "Reference" });
    }

    ...
}

このシナリオで Ninject を使用する最良の方法は何でしょうか?

どんな助けでも大歓迎です。

答え、一種

この質問は、これまでに回答したとおりに検討します。Ninject を機能させることはできましたが、SOLID の Dependency Inversion Principle (DIP) を達成するには、もう少し時間がかかりそうです。

その点で、ドメイン、サービス、データをひとまとめにする必要がありました。別の機会に別の質問を作成し、今のところ通常どおりプロジェクトを進めます。

みんなありがとう。

4

1 に答える 1

3

ユニットテストは、Ninjectなしで実行する必要があります。テスト対象のオブジェクトのインスタンスを作成し、すべての依存関係のモックを手動で挿入するだけです。

統合テストでは、アプリケーションブートストラッパーからのすべてのバインディングを含むカーネルを使用して、置き換えたいものすべてをモックで再バインドできます。たとえば、セッションバインディングを、実際のデータベースの代わりにメモリ内のデータストレージを使用するものに置き換えます。

于 2011-08-03T06:30:58.753 に答える