ドメイン モデル クラスを含む C++ クラス ライブラリを開発しています。データベースやファイルなどのさまざまな永続化メカニズムからこれらのクラスをインスタンス化するためのサポートを追加したいと考えています。クラス ライブラリのユーザーには、永続化メカニズムとの間でデータを転送できるクラスをプログラムするためのインターフェイス (?) を指定する必要があります。
Java で機能すると思われる Data Access Object パターンは知っていますが、それを C++ に適用する方法が正確にはわかりません。他の解決策はありますか？
シリアライゼーションは避けたいと思いますが、1995 年に MFC のアプリケーションの 1 つにこれを実装しました。私たちは独立したオブジェクトのバージョン管理とファイルのバージョン管理を使用するのに十分賢かったのですが、結局は多くの古い厄介なコードになってしまいます。
特定のシナリオ、非推奨のクラス、非推奨のメンバーなどを想像してみてください。それぞれが新しい問題を提示します。圧縮された「XML タイプ」ストリームを使用するようになり、新しいデータを追加し、後方互換性を維持できます。
ファイルの読み取りと書き込みは、データをオブジェクトにマッピングすることから抽象化されています。コア ビジネス オブジェクトを変更することなく、ファイル形式を切り替えたり、インポーター/エクスポーターを追加したりできます。
一部の開発者はシリアライゼーションが好きだと言われていますが、コードベース、プラットフォーム、言語、ツールキットの切り替えはすべて多くの問題を引き起こし、データの読み取りと書き込みはその 1 つであってはなりません。
さらに、独自のキーを使用して標準のデータ形式を使用すると、サードパーティとの連携がはるかに簡単になります。
ブーストシリアライゼーションは、C++ 型のシリアライズを操作するための非常に便利な機能を提供しますが、希望するインターフェイスにどれだけ一致するかはわかりません。侵入型と非侵入型の両方の設計をサポートしているため、非常に柔軟です。
C++ は多重継承をサポートしているため、一般的な永続化 API を使用して永続化メカニズムを継承できます。この場合も、イントロスペクションを使用してクラス メタデータを取得する必要がありますが、永続化レイヤーでこの問題が引き続き発生します。
または、同様のことを行うこともできますが、メタデータを使用して、永続化レイヤーの「ゲッター」と「セッター」を埋めるコード ジェネレーターを駆動します。
通常、永続レイヤーはいずれかのアプローチを使用するため、問題は読み込みメカニズムを永続レイヤーにフックすることです。これにより、問題は単一の永続化レイヤーとは少し異なりますが、別の方向から取り組むことになると思います。持続性フレームワーク上にドメイン クラスを構築するのではなく、サード パーティがデータ アクセス メカニズムをプラグインできる持続性フレームワークのフックを備えた一連のドメイン クラスを提供します。
クラス メタデータとコールバックへのアクセスを提供すると、永続化メカニズムは比較的簡単になると思います。便利な C++ O/R マッピング フレームワークのメタデータ コンポーネントを見て、それらがどのように機能するかを理解します。ドメイン クラスの基本クラスの 1 つでこれを API でカプセル化し、インスタンス化または永続化のための汎用 getter/setter API を提供します。残りは、永続層を実装する人次第です。
編集： あなたが説明しているプラグ可能な永続化メカニズムのタイプを備えたC++ライブラリは考えられませんが、このタイプの機能を追加できるPythonで何かをしました。基本的な原則はおそらく C++ で動作するように適合させることができますが、特定の実装では Python の機能を使用し、C++ に直接相当するものはありませんでした。
__getattr()__Python では、とをオーバーライドすることで、インスタンス変数へのアクセスをインターセプトできます__setattr()__。永続化メカニズムは、実際にはバックグラウンドで独自のデータ キャッシュを維持していました。機能がクラスに混合されると (多重継承によって行われる)、メンバー アクセスのデフォルトのシステム動作が上書きされ、クエリされる属性が辞書内の何かと一致するかどうかがチェックされます。これが発生した場合、データ キャッシュ内の項目を取得または設定するために呼び出しがリダイレクトされました。
キャッシュには独自のメタデータがありました。データ モデル内のエンティティ間の関係を認識し、データにアクセスするために傍受する属性名を認識していました。これが機能する方法により、データベース アクセス レイヤーから分離され、(少なくとも理論的には) 永続化メカニズムをさまざまなドライバーで使用できるようになりました。たとえば、ドライバーを XML ファイルにシリアル化するドライバーを作成できなかった固有の理由はありません。
このようなものを C++ で機能させるのは少し手間がかかり、このシステムの場合のようにオブジェクト キャッシュへのアクセスを透過的にすることはできないかもしれません。オブジェクトの状態をキャッシュにロードしてフラッシュする明示的なプロトコルを使用するのがおそらく最適です。これに対するコードは、キャッシュ メタデータからの生成に非常に適していますが、これはコンパイル時に実行する必要があります。テンプレートを使用したり、演算子をオーバーライドしてアクセス プロトコルをより透過的にすることで、何かできるかもしれませんが->、これはおそらく無駄なことです。
boost serializationを見たいと思うかもしれません。使用したことがないので、推奨するかどうかはわかりません。Boost ライブラリは通常、高品質です。