45

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

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

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

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

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

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

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

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

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

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

4

8 に答える 8

11

私は、ほとんどのものと同様に、そのスライディングスケールを主張します。永続性の特性を持ちたいと私たちが作るものがあります。スケールの一端には、この1つのことだけを特定の方法で永続化するようにカスタム構築された、すべての根性、依存関係、およびコードが含まれていることがあります。スケールのもう一方の端は、魔法のように発生するものです。トークンを追加したり、プロパティをどこかに設定したりするだけで、そのことが「持続する」だけです。スケールの魔法の側面に到達するために、魔法が起こるのを助けるフレームワーク、設計ガイドライン、規則などがあります。NHibernateよりも要件と制限が少ないが、同じ目標を追求したツールを作成できると主張できると思います。その架空のツールは、私たちの規模に沿ったものになるでしょう。

「永続性の無知」という言葉がとても好きかどうかはわかりません。実際には、オブジェクトが実装、バッキングストア、キャッシュなどを認識していないことについてです。ただし、オブジェクトは通常、永続的であるかどうかを認識しています。しかし、それは単なるセマンティクスです。

于 2009-12-29T14:08:52.833 に答える
7

「Persistence Ingorance」の理解 (または定義) が間違っているとは思いません。

本当の問題は、漏れやすい抽象化の問題です。簡単に言うと、既存のテクノロジーでは、真の PI を実装することが非常に困難になっています。

于 2009-12-29T14:38:00.337 に答える
4

永続的無知クラスは、永続フレームワークに関連付けられていないクラスです。

つまり、クラスは永続性フレームワークが存在することをまったく認識せず、そのフレームワークによって定義されたクラスから継承したり、その永続性フレームワークが機能するために必要なインターフェイスを実装したりしません。

于 2009-12-29T14:14:28.137 に答える
4

私はMikebに同意します-「持続性の無知」はスライドスケールであり、特定のORMの真/偽のプロパティではありません。

真の 100% PI の私の定義は、他のクラスを変更することなく、他のクラスとどのように複雑でリンクされていても、可能な限りすべての POCO クラスを永続化できるということです。

ID フィールドの追加、属性による装飾、ORM クラスからの継承、RDB の基礎となるテーブルに適切にマップされるようにクラスを設計する必要がある - すべて「PI スコア」を 100% 未満に減らします。

これは、Fluent NHibernate Automapping を使用することを選択したということです。これは、私が調べた ORM オプションの中で最も高い PI スコアを持っているように思われるためです。

于 2009-12-29T16:32:36.300 に答える
1

私はあなたの定義に同意します：

したがって、オブジェクトが永続化フレームワークの使用を容易にするが、永続化ロジック自体を実行しない場合、「永続化無視」が真であると言うのは合理的ですか?

クラスのコード (属性とは対照的に) には、永続性に固有の機能はありません。永続化のためにデフォルトのコンストラクターが必要になる場合がありますが、実際に永続化を行うコードはありません。パーシスタンス レイヤーは大幅に変更でき、異なるデータベースを使用でき、ビジネス ロジックは変更されません。

于 2009-12-29T14:02:40.677 に答える
0

特定の永続性-無知フレームワークに必要な特定の小さな制約があるかもしれませんが、それでも永続性-無知はそのまま残ります。

ドメインモデルのクラス（NHibernateで透過的に永続化される）には、「動的に」構築できるように引数なしのコンストラクターが必要ですが、フレームワークによって指定された特定の基本クラスを持つ必要はなく、または、特定のフレームワーク指定のメソッドをオーバーライドします。

于 2009-12-29T14:08:18.153 に答える
0

私の意見では、「持続性の無知」はモデル (ドメイン モデル、ビジネス モデル、またはそれを何と呼ぶか​​) の特性です。このモデルは、抽象化 (リポジトリと呼ばれることもあります) を介して含まれるエンティティのインスタンスを取得するため、永続性を無視します。これらの抽象化は、ORM を直接使用することで実装できますが、自分で述べているように、モデルに本来属していないオブジェクトに要件が追加されることがあります。したがって、特定の ORM のいくつかの要件に準拠するモデルが 100% 永続性を無視しているとは言えません。

于 2009-12-29T14:17:00.113 に答える