問題タブ [persistence-ignorance]

NHibernate と Linq2Sql について簡単に説明しました。また、Entity Framework をのぞいてみるつもりです。

私がこれらの ORM について話すときに提起される質問は、「彼らはスケーリングできない」ということです。Google からは、うまくスケーリングできるという印象を受けますが、最終的には、支払うべき代償があるに違いないと思います。

既存のドメイン層があります。Linq to SQL を使用して永続層を開発したいと考えています。現在、外部マップ ファイルを使用しています。子コレクションに遅延読み込みを使用しようとしていますが、うまくいきません。EntitySet または EntityRef を使用せずに、Linq to SQL を使用して遅延読み込みを実装する方法はありますか。

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

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

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

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

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

私は自分のドメイン モデルを可能な限り持続性を考慮しないように書こうとしています。私が現在行っている唯一のことはvirtual、NHibernate が遅延読み込みのためにそれを必要とするため、すべてのプロパティとメソッドをマークすることです。

私のドメイン モデル アセンブリでは、いくつかのリポジトリ インターフェイスを定義します。

次に、データ アセンブリがあります。これはNHibernateを参照し、その存在を知っています。これは、これらのリポジトリ インターフェイスを実装するアセンブリです。

等々。

ここで、リポジトリにトランザクション機能を実装したいと考えました。そのためBeginTransactionに、IRepository インターフェイスにメソッドを追加します。ただし、NHibernate.ITransactionドメイン モデルの永続性を無視し、ドメイン モデル アセンブリから NHibernate のアセンブリを強制的に参照したくないため、戻り値の型を として定義することはできません。

あなたならどうしますか？

インターフェースにa void BeginTransaction()、 a void Commit()、および aメソッドを単純に実装し、リポジトリの実装でオブジェクトを内部的に管理しますか?void RollBack()ITransaction

それとも、リポジトリのメソッドを使用する代わりに、オブジェクトを公開しITransactionて、クライアントがトランザクションを直接管理できるようにする方法を見つけますか?

ありがとう！

永続性の無視は、通常、標準の .NET オブジェクト (または、本当に名前を付けることを主張する場合は POCO) を永続化および取得する機能として定義されます。そして、標準的な .NET オブジェクトの一見広く受け入れられている定義は次のとおりです。

「...インフラ関連の理由で何かを追加することなく、目の前のビジネス問題に集中する通常のクラス...」

ただし、NHibernate を持続性の無視を可能にするフレームワークとして説明している人々を目にしますが、それは標準の .NET オブジェクトでは動作せず、特定の設計要件に準拠する標準の .NET オブジェクトのみで動作するフレームワークです。たとえば ( source ):

• すべてのクラスにはデフォルトのコンストラクターが必要です
• クラスがアンシールされ、すべてのメンバーが仮想でない限り、一部の機能は動作しません
• Equals/GetHashCode を悪用しない限り、オブジェクト ID は正しく機能しません

(余談: 誰かが動揺する前に、ここで NHibernate を選択するつもりはありません。これは、持続性の無視を許可すると思われるフレームワークのよく引用される例にすぎません。同様の議論が、同じことを主張する他の ORM に適用できると確信しています。 .)

クラス自体には永続化フレームワーク固有の属性や基本クラスなどはありませんが、選択した永続化フレームワークでの使用を容易にするために一連の設計ガイドラインに従う必要があるため、私にとっては実際には「永続化に無知」ではありません。永続化フレームワークの要件を念頭に置いて、クラスを設計および実装する必要があります。あなたがそれを知らない場合、クラスはそれで動作しない可能性があります。

[Serializable]「永続性の無視」/「POCO」の定義で問題を抱えているのは、概念的に、これがまたは[DataContract]または[XmlType]または他の永続性フレームワーク固有の注釈などの属性を追加することと実際にどのように異なるかがわからないことですそのフレームワークを使用してエンティティの永続化と取得を容易にします。

では、「持続性無知」とは一体何なのでしょうか？

明らかに、「通常のクラス」を永続化できるという定義は誤りです。なぜなら、NHibernate のクラスは、フレームワーク固有のクラスを参照しない限りは通常のクラスにすぎませんが、デフォルト コンストラクターなどの通常とは異なる設計の選択が必要なため、非常に優れているからです。 -可変型の仮想メンバーと Equals/GetHashCode の実装。

したがって、オブジェクトが持続性フレームワークの使用を (設計および構造において、またはフレームワーク固有の注釈の使用によって) 促進するが、それ自体は持続性ロジックを実行しない場合、「持続性無視」が真であると言うのは合理的ですか?

典型的なOrderとOrderItemの例を考えてみましょう。OrderItemがOrder Aggregateの一部であると仮定すると、Orderを介してのみ追加できます。したがって、新しいOrderItemをOrder に追加するには、Repository を介して Aggregate 全体をロードし、新しいアイテムをOrderオブジェクトに追加して、Aggregate 全体を再度永続化する必要があります。

これには多くのオーバーヘッドがあるようです。Orderに 10 個のOrderItemsがある場合はどうなるでしょうか。このように、新しいOrderItemを追加するだけで、 10 個のOrderItemを読み取る必要があるだけでなく、これら 10 個のOrderItemをすべて再度挿入する必要があります。(これは、Jimmy Nillson が彼の DDD の本で採用したアプローチです。Aggregate を永続化するたびに、彼はすべての子オブジェクトをクリアしてから、再度挿入します。これにより、子の ID が変更されるため、他の問題が発生する可能性があります。データベースの IDENTITY 列のために毎回変更されます。)

Unit of Work パターンを Aggregate Root に適用して、何が変更されたかを追跡し、それらの変更のみをコミットすることを提案する人もいると思います。しかし、永続化ロジックがドメイン モデルに漏れているため、これは永続化無視 (PI) の原則に違反しています。

誰もこれについて前に考えたことがありますか？

モッシュ

私は初めて小さなプロジェクトでPOCOを使ってEF4を試しています。私のリポジトリ実装では、渡されたPOCOが新しい場合はリポジトリに追加するメソッドAddOrUpdateを提供したいと思います。それ以外の場合は、何もしません（SaveChangesが呼び出されたときに更新されたPOCOが保存されるため）。

私の最初の考えはこれを行うことでした：

ただし、その結果、 「サポートされていない非スカラー変数の参照NotSupportedException」で説明されているようになります（ボーナス質問：なぜサポートされないのですか？）

パーツを削除しContains、常にAddObjectを呼び出すだけで、次のようになりますInvalidStateException。

同じキーを持つオブジェクトは、ObjectStateManagerにすでに存在します。既存のオブジェクトは変更されていない状態です。オブジェクトは、追加された状態にある場合にのみ、ObjectStateManagerに再度追加できます。

したがって、EF 4は、これがキーに基づく重複であることをどこかで明確に認識しています。

AddOrUpdateが呼び出されたときに、リポジトリが新しいオブジェクトまたは既存のオブジェクトのPocosを更新して、後続のSaveChanges（）の呼び出しが正しく行われるようにするための、クリーンで効率的な方法は何ですか？

オブジェクト自体にisNewフラグを付けることを検討しましたが、実用的な範囲で永続性を無視しようとしています。

私はASP.NETMVCを初めて使用し、PHPMVCのバックグラウンドを持っています。それは一種の厄介な移行でした（私の質問の履歴を参照してください）。

理論上、.Netの世界で非常に気に入っているのは、モデルが永続性にとらわれないという考えです。しかし、この場合、モデルへの変更を保存する適切な方法は何ですか？$model->save();PHPでは、変換を行った後に呼び出すだけです。C＃では、その方法がわかりません。

これは適切ですか？

これについて私が間違っていると思う唯一のことは、通常、コントローラーがこの方法でデータアクセス層に直接アクセスすることを望まないということです。以前は、PHPランドでは、基本的に、コントローラーはモデルとビューにのみアクセスしていました。

関連するコレクションを使用して切り離されたエンティティを変更します。例:

Person と Address は POCO です。

エンティティを添付して変更を保存すると、コレクションの変更が検出されません。住所 (追加および削除されたアイテム) を持つ個人を更新するにはどうすればよいですか?

コレクションを手動で追跡する必要がありますか?

編集

切り離されたPOCOの同期は手動で行う必要があります... EFはコレクションのマージソリューション（ナビゲーションプロパティと関係）を目的としていません:(

現在のコレクションと元のコレクションを比較し、違いを検出します