「永続的な無知」とは正確には何ですか？

Question

持続性無知は、通常、標準の.NETオブジェクト（またはそれらに名前を付けることを本当に主張する場合はPOCOS）を持続および取得する能力として定義されます。そしてa 標準の.NETオブジェクトの一見よく受け入れられている定義 は：

「...インフラストラクチャ関連の理由で物を追加せずに、手元のビジネス上の問題に焦点を当てる通常のクラス...」

しかし、私はnhibernateを持続性の無知を可能にするフレームワークとして説明する人々を見ていますが、それは取り組むことができないフレームワークです どれか 標準の.NETオブジェクト、たとえば、特定の設計要件に付着する標準の.NETオブジェクトのみ（たとえば）ソース):

• すべてのクラス しなければならない デフォルトのコンストラクターを持っています
• クラスが封印されておらず、すべてのメンバーが仮想でない限り、一部の機能は機能しません
• 等しい/gethashcodeを悪用しない限り、オブジェクトのアイデンティティは正しく機能しません

（さて：誰かが動揺する前に、私はここでnhibernateを選ぶつもりはありません。それは、持続性の無知を可能にすると思われるフレームワークの頻繁に引用されている例です。 。）

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

「永続的無知」/「ポコ」の定義に問題があるのは、概念的には、これが本当に属性を追加することとはまったく異なる方法がわからないということです。 [Serializable] また [DataContract] また [XmlType] またはその他の持続性フレームワーク固有の注釈 促進します そのフレームワークを使用したエンティティの持続性と検索。

それで、「永続的な無知」とは何ですか？

明らかに、「通常のクラス」を持つことができるとの定義は、nhibernateのクラスはフレームワーク固有のクラスを参照していない場合にのみ通常のクラスであるため、誤acyです。 -Virtual MembersおよびEquals/GethashCodeの可変型に関する実装。

したがって、オブジェクトが持続性フレームワークの使用を促進する場合（設計と構造のいずれかによって、またはフレームワーク固有の注釈の使用による）場合、「永続的無知」が真であると言うのは合理的ですか？

Answer 1

私は、ほとんどのものと同様に、それはスライドスケールだと主張します。永続性の特性を持ちたいと思うものがあります。スケールの一方の端には、このことがすべての勇気、依存関係、コードがあり、この1つのことを特定の方法で持続するようにカスタム構築されたコードがあります。スケールのもう一方の端には、魔法のように起こるものがあります。トークンを追加したり、そのことを「ただ持続する」ことを引き起こす場所にプロパティを設定すること以上のことをしていなくても。スケールの魔法の側面に到達するために、魔法が起こるのを助けるフレームワーク、デザインガイドライン、慣習などがあります。 Nhibernateよりも少ない要件と制限があるが、同じ目標を追求したツールを作成できると主張できると思います。その仮想ツールは、私たちのスケールに沿ってさらに進むでしょう。

「永続的な無知」という用語がとても好きであることはわかりません。それは本当に、オブジェクトが実装、バッキングストア、キャッシュ、そのようなことについて無知であることについてです - オブジェクトは通常、それが永続的であるかどうかを認識しています。しかし、それは単なる意味論です。

Answer 2

「永続的なインゴランス」のあなたの理解（または定義）が間違っているとは思わない。

本物 問題はの問題です 漏れやすい抽象化. 。簡単に言えば、既存のテクノロジーがそれを作成します とても 真のPIを実装するのは難しい。

Answer 3

私はMikebに同意します - 「持続性無知」は、特定のORMの真/偽の特性ではなく、スライドスケールです。

真の100％PIの私の定義は、クラスを変更せずに、他のクラスにどれほど複雑でリンクしていても、可能なPocoクラスを維持できることです。

IDフィールドの追加、属性で飾る、ORMクラスから継承し、クラスを設計する必要があるように、RDBの基礎となるテーブルに適切にマッピングされます。

これは、Fluent Nhibernate Automappingを使用することを選択したと言いました。

Answer 4

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

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

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

Answer 5

持続的な無知クラスは、持続性フレームワークに結び付けられていないクラスです。

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

Answer 6

特定の持続性と無防備なフレームワークに必要な特定のマイナーな制約があるかもしれませんが、それでも持続性イノランスはそのまま残っています。

ドメインモデルのクラス（nhibernateで透過的に持続）には、「動的に」構築できるように、アピメントなしコンストラクターが必要ですが、特定の基本クラスをフレームワークによって決定する必要はありません。または、特定のフレームワーク指定方法をオーバーライドします。

Answer 7

私の意見では、「永続的無知」はあなたのモデルのプロパティです（ドメインモデル、ビジネスモデル、またはあなたがそれを参照するかもしれないもの）。このモデルは、抽象化（リポジトリと呼ばれることもある）を通じて含まれるエンティティのインスタンスを取得するため、持続性が無知です。これらの抽象化 できる ORMを直接使用することで実装されますが、自分自身を述べるとき、これはモデルに自然に属していないオブジェクトに要件を追加することがあります。したがって、特定のORMのいくつかの要件を順守するモデルは、100％持続性が無知であるとは言いません。

Answer 8

ドメインまたはあなたのアプリケーションのクラスを使用してPersisrtenceの無知を実装できます。ドメインオブジェクトを永続化する場合、Persistenceクラスにマッピングし、Persistenceオブジェクトを使用して他のフレームワークo nhibernateで保存することができます

ドメインクラスは、情報がどのように保持されるかを無視する必要があります。そのため、永続的なフレームワーク（空のコンストラクター、仮想プロパティなど）のルールを含める必要はありません。

これらの永続的なフレームワークルールは、永続性クラスにあります。