作業単位のパターンに関するいくつかのアドバイスを探しています。作業単位の単位
作業ユニットのコミットは複数回か1回だけ呼び出されてから、オブジェクトをガベージ・コレクションのために残していますか?
作業単位を挿入することをお勧めしますか、オブジェクトに何らかの作業を依頼するときにメソッド呼び出しで渡すべきですか?
作業単位のパターンに関するいくつかのアドバイスを探しています。作業単位の単位
作業ユニットのコミットは複数回か1回だけ呼び出されてから、オブジェクトをガベージ・コレクションのために残していますか?
作業単位を挿入することをお勧めしますか、オブジェクトに何らかの作業を依頼するときにメソッド呼び出しで渡すべきですか?
作業単位パターンを実装するタイプのインスタンスには、通常、そのライフタイムを制御する必要のある単一の所有者があります。 Commit
、Open
、Close
、およびDispose
のようなメソッドは、型を明示的に制御する(または、必要に応じて抽象化の背後に置く)ことを強く示すシグナルです。
作業単位インスタンス自体を挿入するのが良いですが、そのような作業単位を作成する方法を知るタイプのファクトリを挿入してください。
この場合の作業単位はコンテキストとして機能し、他のオブジェクトが同じコンテキストで操作を実行する必要がある場合(たとえば、操作をアトミックに保つために)、それを渡す必要があります。これは次のようになります。
public class MyCommand
{
private readonly IUnitOfWorkFactory factory;
public MyCommand(IUnitOfWorkFactory factory)
{
this.factory = factory;
}
public void Execute()
{
using (var context = this.factory.CreateNew())
{
this.DoSomeNiceThings(context);
context.Commit();
}
}
}
多くのDIフレームワークでは、オブジェクトとその依存関係を実行するコンテキストを定義することができます。これにより、作業単位自体を注入し、同じインスタンスをすべての依存関係に挿入することができます。これは非常に便利な機能ですが、コードの正確性は作業ユニットのスコープを構成する方法に依存するため、この特定のシナリオでは何もしません。これにより、コードは非常に暗黙的になり、従うのが難しくなり、中断しやすくなります。 IMOのこのような機能は、消費者が依存関係を気にしないというシナリオで特に有用です。したがって、この機能はパフォーマンスの最適化、キャッシュ戦略の実装などに非常に便利です。
は ガベージコレクションのためのオブジェクトを残し、その後の作業 と呼ばれる複数回の単位またはちょうど1時間 にコミットしますか?
Commit
を複数回呼び出すかどうかは、どのように設計するかによって異なります。私のプロダクション・アプリケーションでは、トランザクション内で自分の作業単位を実行することが多いため、ビジネス操作をアトミックに保ちながらデータベースに操作をコミットすることができます(データベース生成キーの取得など)。
こちらがお役に立てば幸いです。
作業単位の背後にあるアイデアは、単一の方法(たとえば、特定の役割を持つユーザーを追加し、ユーザーが追加され、役割が関連付けられているユーザーと)。
これらの変更を「バッチアップ」して一度に実行する作業単位を使用します(通常はトランザクションを介して実行します)。
本当に、作業単位ごとにコミットを1回呼び出すだけです。エンティティ・フレームワーク/ nhibernateのようなほとんどのORMは、単一の作業単位を介して複数のコミットを実行できます。それぞれの作業単位は、作業単位を表す特定のトランザクションに関連付けられています。
私は、あなたのアプリケーションに作業単位(抽象化レイヤーとしてLINQを使用)を書く、偽装する、注入するというブログ記事を書いています。それはあなたにとって興味深いかもしれません:http://bit.ly/gHLubu。 – Steven