0

私は、EFコードファースト、リポジトリ、作業単位などについて、信じられないほどの量のブログ/ドキュメントなどを調べてきました。

次のプロジェクトで以下を処理する便利なフレームワークを作成しようとしています。

  1. Web環境（HttpContext）とスタンドアロン（Windowsサービスなど）の両方
  2. 特定のエンティティのリポジトリを定義するか、単純なクエリに汎用リポジトリを使用するかを選択できます。

EFをリポジトリにカプセル化しないことにしました。別のORMへの切り替えをいつ検討するかわかりません。

そこで、次のようなことを思いついたので、よろしくお願いします！:)

namespace Data.Repositories
{
internal class DbContextInstance
{
    public static readonly DbContext Context;

    static DbContextInstance()
    {
        if (System.Web.HttpContext.Current != null)
        {
            if (System.Web.HttpContext.Current.Items["__DBCONTEXT"] == null)
                System.Web.HttpContext.Current.Items["__DBCONTEXT"] = new MyDbContext();

            Context = System.Web.HttpContext.Current.Items["__DBCONTEXT"] as MyDbContext;
        }
        else
        {
            if (Context == null)
                Context = new MyDbContext();
        }
    }
}

public class GenericRepository<TEntity> : IDisposable where TEntity : class
{
    //Implementation of repo. Similar to GenericRepository here: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
    //whenever I need to access the context I'm using DbContextInstance.Context 
}

上記の一般的なリポジトリでは、DbContextInstanceがそれを心配しているので、DbContextを渡すことを心配する必要はありません（私が言及したリンクのように）。これは、接続文字列などを構成できる単一のポイントです。その部分は単純にしましたが、どこかから接続文字列名を読み取るように拡張できます。

GenericRepoはIDisposableです-DisposeメソッドでContextを破棄します。上記のコードは、セッション（HTTPリクエストまたはEXEアプリの存続期間）にコンテキストが1つしかないことを確認します。もちろん、処分されない限り。

作業クラスのユニットは、単にリポジトリをインスタンス化し、それらと対話します。それらもIDisposableになり、リポジトリを破棄します。

DBに対してテストとモックアップを行います。DBをリセットし、初期データを事前入力するためのスクリプトがあります。物事をエミュレートするモックアップではなく、本物に対してテストするのが最善だと思います。

このコードは、さまざまな場所からの断片と私自身の創造性の一部です。

アプリがすでに稼働しているときに、後で苦痛を引き起こす可能性のあるものを見つけることができますか？私の顔に投げてください！;）

ありがとう！:)

4

1 に答える 1

3

コンテキストは短命でなければなりません - あなたのコードは、コンテキストが長寿命で共有されることを暗示しているようです。これはあなたを悲しませます。

于 2012-08-31T12:32:45.230 に答える