5

永続性の無視/単体テストなどを可能にするために、リポジトリと作業単位のパターンに従うシステムを構築しようとしています。ロールバックの処理に関するアドバイスを探しています。理想的には POCO を使用したいのですが、いくつかの断片を提供するために、少なくともインターフェイスを実装する必要があると思います。

したがって、1 つのコンテキスト/作業単位である 2 つのリポジトリがあるとします。

1 つの項目を追加し、別の項目を修正し、3 つ目の項目を削除します。2 番目のリポジトリについて繰り返してから、ロールバックを呼び出します。

過去に、これには DataSet に似たものを使用しました。各オブジェクトには、pendingNew、pendingAmended、pendingDeleted、clean の状態があります。ロールバック用のオブジェクトの最後に保持されたバージョンのコピーもあります。

これをどのように実装しますか？

編集：

わかりました、これが私が実際に頭を悩ませようとしていると思うことです。パターン化する準備をしてください:)

最終的にプロジェクトは WPF MVVM です。そのため、ここにある店舗のモデルを調べています。

モデルが提供する必要がある機能を提供するために、モデルは UOW とリポジトリを使用する必要があると思いますが、モデルをリポジトリのアイデアと混同しようとしてきたと思います。その方がいいですか？

完全な永続性を無視したいので、ドメインに Customer、Order、および OrderLines が含まれていると想像してください。

GUI には、ユーザーが顧客の詳細、注文の詳細、および 1-n OrderLine の詳細を入力できる 1 つのボタンの新しい注文があるとしましょう。彼は保存を押してデータベースに移動しますが、キャンセルを押してもデータベースに移動しません。

したがって、この場合、モデルは CustomerRepository に顧客を要求し、次に OrderRepository に新しい Order を要求し、次に OrderLineRepository に新しい各 Line を要求し、Unit of Work にそれらを保存するように指示します。

それは合理的に聞こえますか？それは私にはそうです、私はそれが分離が定義される場所だと思います。モデルとリポジトリの間に別の API を用意したいと思っています。いいえ、それはばかげています。

編集 2: これは、少し役に立った優れた記事です。

4

3 に答える 3

6

作業単位とリポジトリクラスは、MSDNで説明されている方法と同様に設計しました。このクラスの基本的な考え方は、IUnitOfWorkすべてのデータベース作業自体を処理することです。

次に、オブジェクトを開くメソッドを（IUnitOfWorkクラスと実装に）追加してから、メソッドを追加しました。このメソッドは、トランザクションをデータベースにコミットするか（trueの場合）、トランザクションをロールバックする（falseの場合）ことにより、トランザクションのクローズを処理します。BeginTransaction()TransactionScope()EndTransaction(bool commit)

これにより、複雑なトランザクションを制御して、複数のコミットをロールバックできるようになります。

編集： 私の考え方は、UnitOfWorkオブジェクトにリポジトリについて認識させたいということであり、その逆ではありません。これは私の意見です、そしてあなたは反対が好きな人々を見つけるでしょう、しかしここに理由があります。

何らかの方法でデータベースを処理する場合は、現在の作業単位によってすべてが制約されるようにする必要があります。したがって、私にとっては、リポジトリに作業単位にアクセスさせるのではなく、リポジトリにアクセスするために作業単位を通過することは論理的に理にかなっています。

また、異なるデータベースに分岐して複数のことを行う必要がある場合（たとえば、履歴データがライブデータとは異なるデータベースに書き込まれる場合、またはデータベースの水平分割を行う場合）、各データベースにはそれはそれ自身の仕事の単位です。その理由は、リポジトリに作業単位を知らせる場合、データベースごとに1つの作業単位を作成する必要があり、さらに、アクセスする必要がある作業単位ごとに必要な各リポジトリのコピーを作成する必要があるためです。

最後に、作業単位を介してのみアクセスされるようにリポジトリへのアクセスを維持することで、開発者はAPIをシンプルに保つことができます。手始めに、1つの作業単位オブジェクトと必要な多くのリポジトリオブジェクトではなく、1つのオブジェクト（作業単位）をインスタンス化するだけで済みます。これにより、コードが単純になり（imho）、開発者にとってエラーが発生しにくくなります。

于 2011-02-10T14:19:16.600 に答える
2

It's difficult to say for sure without more detail, but I'd look into implementing from the IDbConnection interface and associated interfaces. It gives you an interface most C# coders with any experience will be familiar with.

Under the hood, to be honest, it really depends on the efficiency if your storage mechanism. If it handles lots of changes efficiently, then you're probably better off having your rollback mechanism build a list of actions that it should take to do a rollback, which is discarded on a 'commit'. If on the other hand updates are expensive, then have you transaction mechanism maintain a list of actions to do on a commit, which are discarded on a rollback. You also need to think about whether or not other code should see updates prior to a commit; with the former approach they will, with the latter, they won't.

于 2011-02-10T14:00:25.937 に答える
0

これを実装するには、NHibernate や Entity Framework などのフレームワークを使用します。:) NHibernate を使用すると、POCO を使用でき、すべての配管がすでに行われています。

于 2011-02-10T14:01:58.533 に答える