2

私は最近、Entity Framework4.3とDependancyInjectionを使用してMVC3を学習しているので、後日単体テストを実装できます。現在、さまざまな例で見たいくつかの関数を実装しようとしていますが、依存関係インジェクションの使用に起因すると思われるいくつかの問題が発生したため、どこが間違っているのかを誰かに指摘してもらいたいと思います。

私の最初の質問は非常に単純です。私が見たほとんどのMVC3の例では、データベースへのアクセスはコントローラーで行われますが、依存関係の注入を使用する場合は、このコードを実装されたリポジトリにリファクタリングする必要があるようです。これは正常で正しいですか？

私の2番目のより詳細な問題は、この単純な例を扱うことです。

このメソッドは、オンラインの例（ここ）からほとんどコピーされたリポジトリクラスにあります。ただし、パーツに関してエラーが発生Includeし、インテリセンスは変数が文字列である必要があると言っています。前述のリンクから元のコードを試しましたが、それは正常に機能します。プロジェクト間の唯一の大きな違いは、依存関係の注入を使用していることです。

public ExampleUser GetStruContractUser(int id)
{
    ExampleUser user = context.ExampleUsers
        .Include(i => i.ExampleRoles)
        .Where(i => i.UserID == id)
        .Single();

    return user;
}

Includeパラメータを次のように変更すると正常に機能します。

public ExampleUser GetStruContractUser(int id)
{
    ExampleUser user = context.ExampleUsers
        .Include("ExampleRoles")
        .Where(i => i.UserID == id)
        .Single();

    return user;
}

参考までに、これは私が使用しているDbContextクラスです。

public class EFDbContext : DbContext
{
    public DbSet<ExampleUser> ExampleUsers { get; set; }
    public DbSet<ExampleRole> ExampleRoles { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
        modelBuilder.Entity<ExampleUser>().ToTable("User", "MySchema");
        modelBuilder.Entity<ExampleRole>().ToTable("Role", "MySchema");

        modelBuilder.Entity<ExampleUser>()
            .HasMany(m => m.ExampleRoles)
            .WithMany(t => t.ExampleUsers)
            .Map(a =>
            {
                a.MapLeftKey("UserID");  // your PK column name in user table
                a.MapRightKey("RoleID"); // your PK column name in role table
                a.ToTable("UserRole", "MySchema");  // your join table name
            });
        }
    }

これは、依存関係の注入を使用したことによる問題ですか、それとも私が誤解している何か他のことが起こっていますか？

さらに詳しい情報が必要な場合は、お問い合わせください。提供させていただきます。

どうもありがとう。

4

2 に答える 2

2

質問1： DIを使用しても、リポジトリパターンを使用する必要はありません。実際、それらは関連していません。これは、コントローラークラスをデータベースコンテキストクラスに緊密に結合することを回避し、それらのクラスをより簡単にテストできるようにするための優れた方法です。リポジトリを使用すると、DBにアクセスする方法の実装の詳細を非表示にすることができ、それが発生した場合にORMを切り替えることができます（これは決して行われません）。リポジトリは、DbContextのインターフェイスを提供するためにユーザーに依存しており、DIの使用も同様です。

それでも、インターフェイスを介してDBを使用し、DIを使用していることを確認すると、コントローラーのコンストラクターにDbContextクラスへの参照を挿入し、DIコントローラーに作業を任せることができます。 。

DbContextを定義するインターフェースを渡すよりも、リポジトリーを定義するインターフェースをコントローラーに渡す方が望ましい理由は、後者のインターフェースを作成すると非常に複雑になる可能性があるのに対し、リポジトリーに固執する方がはるかに簡単だからです。ただし、簡単にするために、DbContextを直接使用することから始めて、そこから拡張します。

質問2：

Includeには、テーブルの名前を文字列として含める必要があります。したがって、後者のIncludeの使用は正しく、前者は正しくありません。

私の記憶が正しければ、「。Include（i => i.ExampleRoles.Name）」を実行して、同じことを実現できます。

于 2012-08-26T19:16:13.223 に答える
1

はい、データベースレイヤー（リポジトリ/コンテキスト）を抽出し、それをビジネスレイヤー（コントローラー）に挿入することは非常に正常であり、将来にわたってアプリケーションを保証するための良い方法です。データベースのORMをEntityFrameworkから別のものに変更したい場合はどうなりますか？コントローラと緊密に組み合わせると、大きな頭痛の種になります。

の2番目の問題はinclude、依存関係の注入とは関係ありません。

Includeラムダをdbset使用する場合の拡張子System.Data.Entity。使用する場合は、その参照を含める必要があります。

于 2012-08-26T19:22:11.317 に答える