2013-04-25 11 views
8

LINQと.dbmlファイルを使用してプログラムを作成する場合、コンテキストは1つのみです。しかし、MVCサイトを行うと、各エンティティごとに別々のコンテキストがあるように思えます(これは、MVCチュートリアルでは、「ムービー」コンテキストを使用して、どのように行うかを示しています)。なぜ複数のDbContextクラスですか?

私が持っている:

public class AccountsContext : DbContext 
{ 
    public AccountsContext() 
     : base("DefaultConnection") 
    { 
    } 

    public DbSet<Account> Accounts { get; set; } 
} 

そして、私が持っている:

public class ClientsContext : DbContext 
{ 
    public ClientsContext() 
     : base("DefaultConnection") 
    { 
    } 

    public DbSet<Client> Clients { get; set; } 
} 

私はこれらを呼び出すと、私は次のように、別々のコンテキストを作成する必要があります。

private AccountsContext db = new AccountsContext(); 
private ClientsContext clientsContext = new ClientsContext(); 

...私はLINQを使用するときに、単一のデータベースオブジェクトをインスタンス化するだけでよいことを知っているので、どちらも厄介なことです。

contextblを1つだけ使用する方法はありますか?これはお勧めですか?

答えて

12

1つのコンテキストを使用することからあなたを止めるべきではありません。データベースとそれにアクセスするために使用されるツールは、それ以外のもの(ビジネスロジック、サービスレイヤ、UIなど)とは完全に独立している必要があります。

コンテキストの数または使用方法は、クライアントテクノロジに基づいて変更しないでください。

MVCを使用すると、複数のコンテキストが必要と思われる場合はどうなりますか?そしてあなたを止めさせるのは何ですか?

サンプルがそうした方法であったため、各エンティティにコンテキストを使用する必要があると思われる場合は、そうしないでください。ただ一つの文脈を使ってください。

それが助け場合は、これは単純なコンテキストが複数のエンティティで次のようになります。

public partial class abook_dbEntities : DbContext 
{ 
    public abook_dbEntities() 
     : base("name=abook_dbEntities") 
    { 
    } 

    public DbSet<Entity> Entities { get; set; } 
    public DbSet<Contact> Contacts { get; set; } 
} 

それが助け場合は、一般的な業務フローは次のようになります。

UI - >コントローラ - >ビジネスロジック - >データアクセス - >データベース

データコンテキストはデータレイヤーになります。あなたのロジックはあなたのビジネスロジック層に入ります。

+5

ムービーMVCの例は、具体的かつ意図的に複数のコンテキストを使用しています。 http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/adding-a-model。なぜ、私は知らない。たぶん、それが可能であることを説明するだけです。非常に大規模なアプリケーションでは、これは望ましいことです。企業の各部門、またはおそらくそれぞれの物理データベースのコンテキストを作成することができます。 –

+0

それには正当な理由があるかどうか知っていますか?それで、OPは、その例のために、そうしなければならないと思っていますか? –

+0

それは私の推測だろう。 –

関連する問題