1

永続性を無視したリポジトリパターンを実装しました。IUnitOfWorkリポジトリの実装は、エンティティオブジェクトおよびITable<T>インターフェイスとのみ対話します。目的は、IUnitOfWorkが再利用されないが、単一のトランザクションを表すことです。これまでのところ、メモリ内とLinq-to-SqlバージョンのIUnitOfWorkおよびを実装しましたITable<T>。

私の問題はIUnitOfWork、リポジトリへの注入が原因IUnitOfWorkで、リポジトリが使用されている場所で新しいインスタンスを作成する方法を知る必要が生じることです。これはプラグイン可能であるはずの主要な部分なので、私が何か間違ったことをしたように感じます。一般的な使用パターンは次のようなものです。

FooUnitOfWork unitOfWork = new FooUnitOfWork();
Repository repos = new Repository(unitOfWork);
// ...act upon repos
unitOfWork.Save();

これで、アプリ内のすべてのリポジトリ使用量が正しい作業単位（たとえば、メモリ内、L2Sなど）を取得できるようにするために、他のパターンが必要なようです。

これに最も適したパターンは何ですか？私はこのトピックに関するファウラーの議論を見てきましたが、彼の例はどれもぴったりではないようです。私が持っている抽象化の量は私が望む以上のものであるとすでに感じているので、さらに別の間接参照を構築することは過度に思えます。

現時点では、正しいを生成するように構成できる、ある種のアプリ全体のプロバイダーに傾倒していますIUnitOfWork。私はオフベースですか、それともこれは本当に実装にとらわれないために必要なことですか？

4

2 に答える 2

1

更新：これは実際には故障しませんでしたが、結局は貧乏人のIoCコンテナを作成するだけでした。私はこれらすべてを置き換えることになりました：

UnitOfWorkFactory.Create();

一般化されたCommonServiceLocatorの実装では：

Microsoft.Practices.ServiceLocation.ServiceLocator.Current.GetInstance<IUnitOfWork>();

これにより、すべてのユーザーに同じIoCフレームワークを使用させることなく、依存性注入を使用するライブラリを作成できました。

おそらく、コールバックを設定できる非常に単純なファクトリを使用する必要がありますか？次のような静的メソッドのセットを含めることができます。

public static class UnitOfWorkFactory
{
    private static Func<IUnitOfWork> FactoryMethod;

    public static IUnitOfWork Create()
    {
        if (UnitOfWorkFactory.FactoryMethod == null)
        {
            throw new InvalidOperationException("...");
        }

        return UnitOfWorkFactory.FactoryMethod();
    }

    public static void SetFactoryMethod(Func<IUnitOfWork> factory)
    {
        UnitOfWorkFactory.FactoryMethod = factory;
    }
}

これはどこで壊れますか？

于 2009-08-31T00:02:00.487 に答える
0

Vistorパターンを使用して、IUnitOfWorkインターフェイスの実装を見つけることをお勧めします。

[UnitOfWork(Name="foo")]
public class FooUnitOfWork : IUnitOfWork {}

Repository repo = new Repository("foo");
//stuff happens
repo.Save(); //or repo.Worker.Save();

リポジトリインスタンス内で、検出ファクトリがワーカーを見つけて作成します。

于 2009-08-30T23:56:41.150 に答える