問題タブ [unit-of-work]

この1週間ほど、リポジトリパターンに関する多くの記事やチュートリアルを読んでいます。多くの記事は、リポジトリパターンを作業単位パターンに密接に結び付けています。これらの記事では、通常、次のようなコードを見つけます。

作業単位オブジェクトは、基になるデータストア（私の場合はLDAP経由で通信するディレクトリサービス）内のオブジェクトの追加、更新、または削除を処理することを目的としていることを正しく理解していますか？それが本当なら、それはオブジェクトの検索も処理するべきではありませんか？なぜそれは提案されたUoWインターフェースの一部ではないのですか？

タイトルがこの質問を説明する最良の方法であるかどうかはわかりません。

この本 ( http://apress.com/book/view/9781590599099 ) は、Unit of Work パターンの実装を示しています。こんな感じで少し進みます。

(静的呼び出しと依存関係の問題をしばらく無視します)

著者は、この実装ではコーダーが関連する UoW マーキング メソッドを挿入する必要があり、パターンを選択的に尊重するとエラーが発生する可能性があることに注意しています。ここで、具象アクセサーの長所と短所を踏まえて、次のように UoW 呼び出しを自動化できます。

それで、私の質問は、ドメイン オブジェクトにプロパティを設定するときに、適切な UoW メソッドが呼び出されたことをどのように保証しますか?

私は現在、最初の Linq-to-Sql アプリに取り組んでいます。次のように、dataContext の有効期間が短いデータ アクセス メソッドを実装しました。

clr-properties の変更通知を取得する方法を知りたいです。単一の dataContext がある場合、これは問題ではありません。

問題は、エンティティのインメモリ変更を取得するにはどうすればよいですか?!

2 つの異なる画面で変更できるエンティティがあります。一方の画面での更新は、他方の画面でも表示される必要があります。私が見る唯一の可能性は、アプリケーションの寿命に帰着する、両方の画面と同じ寿命を持つようにすることです。

Unit of Work パターン (要求ごと) と完全なデータバインディング機能の間に摩擦を感じます。何が欠けているか教えてください...

how can I handle exception that is thrown in NHibernate method Flush? I have a action for deleting objects. It loads the objects from repository using posted ids and calls repository.Delete(obj).

Leaving aside that my mapping in NHibernate is not complete and the delete results in "The DELETE statement conflicted with REFERENCE constraint" exception, this is good case to implement the exception hadling for this case.

So the exception is thrown in Flush and the Flush is called in UnitOfWorkPerRequestTask, which is task created and destroyed on every request and it starts and flushes the UnitOfWork (Rhino.Commons.UnitOfWork). This task is registered using Windsor container and LifestyleType.Transient and it is called by HttpApplication inside Begin and EndRequest methods.

Is there any way how to handle this exception in my delete action, so I can notice user that this object cannot be deleted because of some relationships?

The exception stack trace is here (not full):

Thanks for help.

Ayendeのメソッド（http://ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx）を使用して、リスナーを持つエンティティの作成日と更新日を設定していますが、これは影響を受けるエンティティに対してそれらを設定します。作業単位内の他の何も設定しません。

したがって、たとえば、これを行うと、次のようになります。

ノートは作成/更新日を取得しますが、注文は取得しません。作業単位全体に更新を表示させるための秘訣はありますか？または、更新日を設定するために、注文のプロパティを物理的に更新する必要がありますか？

違いがある場合は、S＃arpアーキテクチャも使用しています。

これが私が使用しているコードブロックです：

私は、簡単な答えがあると確信している、および/または以前に解決された設計上の問題を扱っています。私はかなり長い間、読んで、考えて、解決策を探してきましたが、本当に意味のあることは何もないようです。

問題の要点は、私が一連のレガシーシステムとデータベースを扱っており、新しいアプリを構築して古いアプリを置き換えるためにDDDアプローチを採用しようとしていることです。主要な問題は、ドメインエンティティ、値オブジェクト、および集計はビジネス上意味がありますが、永続性を考慮すると、1つの大きな問題があります...集計内のエンティティは現在複数のデータベースに永続化されています。

たとえば、エンティティA、B、およびCがあり、Aが集約ルートであるとします。私はAのリポジトリを持っており、永続性のためにNHibernateセッションの周りで作業ユニットを使用しています。A、B、およびCがすべて単一のサーバー/データベースに永続化されている限り、すべてが素晴らしく問題ありません。ただし、私の場合、AとBは1つのサーバー/データベース上にあり、Cは完全に異なるサーバー/データベース上に永続化されている可能性があります。

私は、従来の知識がこれを決して行うべきではないことを示唆しているかもしれないことを理解していますが、私は遺産を扱っています。確かに、そのうちにデータ層をより論理的なものにリファクタリングする可能性がありますが、今のところ行き詰まっています。私はいつもある程度この問題を抱えているのではないかと思いますし、他の人がこの橋を渡ったと思わざるを得ません。

要するに、私はC＃で、永続性のためのFluent / NHibernate、IoCのためのUnityで構成され、標準の（または少なくとも認識可能な）リポジトリと作業単位のパターンを採用する自家製のフレームワークを持っています。データベースに関しては、MSSQLServerとOracleを扱っています。

何かご意見は？

私が「作業単位」の概念を完全に理解していない可能性があります（おそらく）。基本的に、私はそれをオブジェクト指向環境で使用される一種の広範なトランザクションと見なしています。作業単位を開始し、オブジェクトを操作し、コミットまたはロールバックします。しかし、これはどのようにしてそれらのオブジェクトの背後にあるデータストアの実際のトランザクションに分解されますか？

単一のDBとORM（NHibernateなど）を備えたシステムでは、それは簡単です。トランザクションはORMを介して維持できます。しかし、カスタムドメインモデルが多くの異なるデータソースを覆い隠しているシステムについてはどうでしょうか。そして、それらのデータソースのすべてがリレーショナルデータベースではありませんか？（このあたりのファイルシステムでは多くのことが行われています。）

今のところ、「SQL2005 DB、SQL2000 DB、DB2 DB、およびファイルシステムをすべて同じ「アトミック」なビジネスオペレーションでトランザクションを維持することはできない」という考えに固執しています。したがって、今のところ、コード内でトランザクションを手動で維持するのは、チームの開発者（通常は互いに独立して作業する）の責任です。各DBには適切なトランザクションを含めることができますが、全体としてのビジネスオペレーションは手動でチェックされ、重要なステップごとにバランスが取られます。

ただし、ドメインの複雑さが増し、標準の開発者の交代が進むにつれて、このアプローチはますます困難になり、時間の経過とともにエラーが発生しやすくなります。

このようなドメインにどのように対処するのが最適か、または以前にどのように対処したかについて、アドバイスや例はありますか？この場合の実際の「ドメイン」はまだ初期段階にあり、プロトタイプとして進化し、ある日、異種のレガシーアプリケーションの大規模なエコシステムを拡張および消費/置換します。したがって、再設計とリファクタリングの余地は十分にあります。

参考までに、私が現在目指している設計の10,000フィートのビューは、次のとおりです。中央のメッセージベースのサービスを呼び出す、可能な限り小さなクライアントアプリケーションの大規模なコレクション。このサービスは「ドメインコア」への入り口であり、1つの大きなMVCスタイルのアプリケーションと考えることができます。リクエストはサービスに対して行われ（「アクション」のように）、ハンドラー（「コントローラー」のように）によって取得されます。手続き的なものは何でもそこに行きます。それらは、すべてのビジネスルールを含むモデルと相互作用します。モデルは、リスナー（「サービス」？この部分はまだ設計が曇っており、改善される可能性があります）がリポジトリ（データベースx、データベースy、ファイルシステム、電子メール、外部リソース）と対話することによって取得および処理するイベントを公開します。すべての陽気に依存関係-それに応じて注入されます。

すべての冗長性について申し訳ありません:)しかし、誰かが何かアドバイスがあれば、私はそれを聞いてみたいです。（特に）そのアドバイスが「あなたのデザインが悪いなら、代わりにこれを試してみてください...」であるとしても、ありがとう！

MVC 2.0に慣れるために、簡単なWebサイトを作成しています。私は1.0からWebフォームを作成しており、MVCへのWebフォームサイトの大規模なオーバーホールを開始する準備をしています。ですから、学習曲線を理解するために、より小さなアプリを構築したいと思います。

そこで、タイムトラッキングアプリケーションを作成します。ASP.NETMVC2.0とLINQtoSQLを使用しています。大規模なWebサイトで使用するため、リポジトリと作業単位を試してみる予定です。

私のデータベースには、Category、Project、Assignment、Userの4つのテーブルしかありません。したがって、LINQ2SQLにはこれらの4つのエンティティがあります。次に、ProjectDetails、ProjectSummary、AssignmentDetailsなどのPOCOを取得します。しかし、それらの統合されたテーブルエンティティはありますか？または、それぞれに独自のリポジトリが必要ですか？それとも、それらは集約リポジトリに収まる必要がありますか？

詳細が必要な場合はお知らせください

ありがとう

EF 4 を使用して新しいプロジェクトを開始することを考えており、いくつかの記事を読んでいると、リポジトリ パターンと作業単位を含む EF に関する記事を見つけました ( http://blogs.msdn.com/b/adonet/archive/2009/ 06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx )

その記事を見ると、ObjectContext を UnitOfWork として使用し、それをリポジトリに渡しています。

私の質問は、2 つの ObjectContext がある場合、つまり 2 つの作業単位がある場合ですが、実際には、これら 2 つのコンテキストで実行されるすべての操作を 1 つの作業単位にしたいのですが、このシナリオは可能ですか? 各コンテキストで save を呼び出したくありません.transactionalにしたいのですが.... transactionscopeを使わずに...

たとえば、操作ログを管理するコンテキストと、注文を管理する別のコンテキストがあります。私のビジネス層には、AddOrder() というメソッドがあるとしましょう。AddOrder() は注文コンテキストを使用して新しい注文を作成しますが、操作ログ コンテキストも使用して新しい操作ログ エントリを作成します。これらは 2 つのコンテキストであるため、両方のコンテキストで save を呼び出してコミットする必要があります....おそらく唯一のオプションは、単一のコンテキストのみを使用することです....

編集: たとえば、OperationalLogContext と OrderContext など、異なるタイプの 2 つのコンテキストを意味しました。

たとえば、データベースに複数のデータベーススキーマがあるとします：HumanRessourcesとInventory。

これらの各スキーマには、複数のテーブルが含まれています。通常、DBを複数のedmxに分割しますか、それともすべてを1つのedmxにまとめますか？

スキーマごとにedmxを作成することを考えていましたが、これがユニターワークパターンにどのように影響するのか疑問に思いました。いくつかの記事を読むと、ObjectContextが作業の単位になります。2 edmxを定義すると、最終的に2つのObjectContext：HumanRessourceContextとInventoryContextになります。つまり、それぞれがユニットオブワークになります。ヒューマンリソース内のエンティティとinventorycontext内のエンティティに加えられたすべての変更をATOMICにしたい場合、これはunitofworkパターンで実現できますか？