1

ロギングの目的で、さまざまなクラス (このため、一般的なアプローチが必要です) をキー値ディクショナリに適合させたいと考えています。これは、「キー値のシリアル化」と見なすことができます。

キーが事前に定義されており、適応させたい入力クラスに応じて、各値が特定の属性に対応していると仮定しましょう。値は常に std::string にカプセル化できます。

これは私のアプローチです：

データベースにダンプできるアダプター クラスを作成します。

#include <keys.h> // enum with possible keys, defining type Key_t

namespace generic
{
    class Adapter
    {
        public:
            Adapter();
            virtual ~Adapter();
            virtual void init() = 0;

        private:
            std::map<Key_t, std::string> _data;
    }
}

考えられるすべてのクライアントについて、アダプタ クラスをその名前空間で特殊化します。これは、(属性に簡単にアクセスするために) クライアントの特定のビジネス オブジェクト モデルとフレンドシップであり、そのコンストラクタの const 参照を介してそのようなモデルのインスタンスを受け取ると仮定します。

例えば

#include <generic/Adapter.h>

#include <client1/bom1.h>
#include <client1/bom2.h>
...
#include <client1/bomN.h>

namespace client1
{
    class Adapter : public generic::Adapter
    {
        public:
            Adapter(const Bom1& bom1,
                    const Bom2& bom2,
                    const BomN& bomN)
            : _bom1(bom1), _bom2(bom2), _bomN(bomN)
            {}

            void init()
            {
                // Explicit data mapping in here
                 _map[NAME] = _bom1._name;
                 _map[TITLE] = _bom2._title;
                 ....
                 ....
            }

        private:
            Bom1 _bom1;
            Bom2 _bom2;
            BomN _bomN;
      }
}

このアプローチについてどう思いますか? c++ でこれを達成するためのより一般的な方法はありますか? あなたのデザインは何でしたか？

ありがとう！

アップデート

新しいクライアントが実装されても、ログ エンジンは変更されません。そのため、適応ロジックはログ エンジンのコアに実装するのではなく、クライアント側に分散する必要があります。ロギング エンジンは、新しいキーが必要な場合にのみ更新されます (これはおそらくデータベース構造の変更を意味します)。

4

1 に答える 1

0

キーと値の両方のシリアル化された文字列を保存していたでしょう。
ここではldbSerialize、デフォルトでブースト シリアライゼーションを使用し、新しいクラスを作成せずに簡単に特殊化できるメソッドを使用しています。キーの新しいタイプごとに、新しい特殊化を追加するだけです。

template <> inline void ldbSerialize<Key32> (string& bytes, const Key32& key) {
  bytes += key.whatever();
}
于 2012-12-28T10:48:53.760 に答える