「永続性の無知」とは正確には何ですか？
永続性の無知は、通常、標準の.NETオブジェクト（または、本当に名前を付けることを主張する場合はPOCO）を永続化および取得する機能として定義されます。そして 標準の.NETオブジェクトの定義としてよく受け入れられているようです は次のとおりです。
「...インフラストラクチャ関連の理由で何かを追加せずに、目前のビジネス問題に焦点を当てる通常のクラス...」
ただし、NHibernateを永続性の無知を可能にするフレームワークとして説明している人がいますが、それでもany標準の.NETオブジェクトでは機能しないフレームワークです。たとえば、特定の設計要件に準拠する標準の.NETオブジェクト（ source ）：
- すべてのクラスmustにはデフォルトのコンストラクターが必要です
- 一部の機能は、クラスが開封され、すべてのメンバーが仮想でない限り機能しません
- Equals/GetHashCodeを悪用しない限り、オブジェクトIDは正しく機能しません
（余談ですが、誰かが動揺する前に、ここでNHibernateを選ぶつもりはありません。これは、永続性の無知を許可すると思われるフレームワークの頻繁に引用される例にすぎません。同様の議論が可能であると確信しています。同じことを主張する他のORMに適用されます。）
クラス自体には永続性フレームワーク固有の属性や基本クラスなどはありませんが、の一連の設計ガイドラインに従う必要があるため、私にとっては実際には「永続性を知らない」わけではありません。 ）選択した永続性フレームワークによる使用を容易にします。永続性フレームワークの要件を念頭に置いてクラスを設計および実装する必要があります。あなたがそれを知らないならば、クラスはそれで働かないかもしれません。
「永続性の無知」/「POCO」の定義で問題が発生しているのは、概念的に、これが[Serializable]や[DataContract]などの属性の追加と実際にどのように異なるのかわからないことです。または[XmlType]、またはそのフレームワークを使用してエンティティの永続性と取得を促進するその他の永続性フレームワーク固有の注釈。
では、「永続性の無知」とは正確には何ですか？
NHibernateのクラスはフレームワーク固有のクラスを参照しない限り普通であるのに対し、デフォルトのコンストラクターなどの通常とは異なる設計上の選択が必要なため、「通常のクラス」を永続化できるという定義は誤りです。 -可変型での仮想メンバーとEquals/GetHashCodeの実装。
したがって、オブジェクトが永続性フレームワークの使用を容易にするが（設計と構造、またはフレームワーク固有の注釈の使用のいずれかによって）、永続性ロジック自体を実行しない場合、「永続性の無知」が真実であると言うのは合理的ですか？
私は、ほとんどのものと同様に、そのスライディングスケールを主張します。永続性の特性を持ちたいと私たちが作るものがあります。スケールの一端には、この1つだけを特定の方法で永続化するようにカスタムビルドされた、すべての内臓、依存関係、およびコードが含まれているものがあります。スケールのもう一方の端は、魔法のように発生するものです。トークンを追加したり、プロパティをどこかに設定したりするだけで、「ただ持続する」だけです。スケールの魔法の側面に到達するために、魔法が起こるのを助けるフレームワーク、設計ガイドライン、規則などがあります。 NHibernateよりも要件と制限が少ないが、同じ目標を追求したツールを作成できると主張できると思います。その架空のツールは、私たちの規模に沿ったものになるでしょう。
「永続性の無知」という言葉がとても好きかどうかはわかりません。それは実際には、オブジェクトが実装、バッキングストア、キャッシュ、そのようなものを知らないことについてです-オブジェクトは通常、永続的であるかどうかを認識しています。しかし、それは単なるセマンティクスです。
「永続性インゴランス」についてのあなたの理解（または定義）が間違っているとは思いません。
realの問題は、 リークのある抽象化 の問題です。非常に簡単に言えば、既存のテクノロジーでは、真のPIを実装することが非常に困難になっています。
私はMikebに同意します-「永続性の無知」はスライディングスケールであり、特定のORMの真/偽のプロパティではありません。
私の真の100％PIの定義は、他の方法でクラスを変更することなく、他のクラスにどれほど複雑でリンクされていても、可能なPOCOクラスを永続化できるということです。
IDフィールドの追加、属性での装飾、ORMクラスからの継承、RDBの基になるテーブルに適切にマップされるようにクラスを設計する必要があります。これらはすべて、「PIスコア」を100％未満に減らします。
そうは言っても、私が調べたORMオプションの中でPIスコアが最も高いように思われるため、Fluent NHibernateAutomappingを使用することにしました。
永続的な無知なクラスは、永続的なフレームワークに関連付けられていないクラスです。
つまり、クラスには永続性フレームワークが存在することをまったく認識しておらず、そのフレームワークによって定義されたクラスから継承したり、その永続性フレームワークが機能するために必要なインターフェイスを実装したりすることはありません。
私はあなたの定義に同意します：
したがって、オブジェクトが永続性フレームワークの使用を容易にするが、永続性ロジック自体を実行しない場合、「永続性の無知」が真実であると言うのは合理的ですか？
クラスのコード（属性ではなく）には、永続性に固有の機能はありません。永続化にはデフォルトのコンストラクターが必要になる場合がありますが、実際に永続化を行うコードはありません。永続層はかなり大幅に変更される可能性があり、さまざまなデータベースが使用され、ビジネスロジックは変更されません。
特定の永続性-無知フレームワークが必要とする特定の小さな制約があるかもしれませんが、それでも永続性-無知はそのままです。
ドメインモデルのクラス（NHibernateで透過的に永続化される）には、「動的に」構築できるように引数なしのコンストラクターが必要ですが、フレームワークによって指定された特定の基本クラスを持つ必要はなく、必要でもありません。または、特定のフレームワーク指定のメソッドをオーバーライドします。
ドメインまたはアプリケーションのクラスと永続性のPOCOクラスを使用して永続性の無知を実装できます。ドメインオブジェクトを永続化する場合は、永続性クラスにマップし、永続性オブジェクトを使用してnhibernateまたは他のフレームワークで保存します。
ドメインクラスは、情報がどのように永続化されるかを無視する必要があるため、（空のコンストラクター、仮想プロパティなど）のような永続化フレームワークのルールを含めないでください。
これらの永続フレームワークルールは、永続クラスに含めることができます。
私の意見では、「永続性の無知」はあなたのモデル（ドメインモデル、ビジネスモデル、またはあなたがそれを参照するかもしれないもの）の特性です。モデルは、抽象化（リポジトリと呼ばれることもあります）を通じて含まれるエンティティのインスタンスを取得するため、永続性に依存しません。これらの抽象化canは、ORMを直接使用して実装できますが、自分で説明すると、モデルに自然に属していないオブジェクトに要件が追加される場合があります。したがって、特定のORMのいくつかの要件に準拠するモデルは、100％永続性を知らないとは言えません。