15

さまざまなプログラミング言語 (C++、C#、および Python) で実装され、ネットワークを介して相互に通信するコンポーネントから構築された分散システムを開発します。システム内のすべてのコンポーネントは、同じビジネス コンセプトで動作し、これらのコンセプトに関しても相互に通信します。

その結果、次の 2 つの課題に非常に苦労しています。

  1. これら 3 つの言語でのビジネス コンセプトの表現を同期させる
  2. これらの言語間でのビジネス コンセプトのシリアル化/逆シリアル化

この問題の単純な解決策は、同じデータ構造 (およびシリアル化コード) を 3 回定義することです (C++、C#、および Python の場合)。

残念ながら、このソリューションには重大な欠点があります。

  • 多くの「コードの重複」が発生します</li>
  • すべてを同期させるには、膨大な量の言語間統合テストが必要です

私たちが検討した別のソリューションは、ProtoBufs や Thrift などのフレームワークに基づいています。これらのフレームワークには、ビジネス概念が定義されている内部言語があり、C++、C#、および Python でのこれらの概念の表現が (シリアライゼーション ロジックと共に) これらのフレームワークによって自動生成されます。

このソリューションには上記の問題はありませんが、別の欠点があります。これらのフレームワークによって生成されたコードは、基礎となるビジネス概念を表すデータ構造と、これらのデータ構造をシリアライズ/デシリアライズするために必要なコードを結合します。

これにより、コード ベースが汚染されていると感じています。これらの自動生成されたクラスを使用するシステム内のコードは、このシリアル化/逆シリアル化ロジック (深刻な抽象化リーク) に「慣れている」ようになっています。

自動生成されたコードをクラス/インターフェースでラップすることで回避できますが、これは単純なソリューションの欠点に戻ります。

説明されている問題を回避するソリューションを推奨できる人はいますか?

4

7 に答える 7

5

Lev、あなたはICEを見たいと思うかもしれません。使用するすべての言語 (C++、Python、.NET (私の知る限り、C# だけでなく、すべての .NET 言語)) へのマッピングを備えたオブジェクト指向 IDL を提供します。ICE はミドルウェア フレームワークですが、そのすべてのポリシーに従う必要はありません。

具体的には、ICE IDL でコンポーネントのインターフェイスを定義し、それらをコードの一部として維持したい場合があります。その後、ビルド ルーチンの一部としてコードを生成し、そこから作業できます。または、ICE が提供するパワーをさらに活用することもできます。

ICE は C++ STL データ構造をサポートし、継承をサポートします。したがって、十分に強力な形式を提供して、時間の経過とともにシステムを徐々に構築し、保守性を高める必要があります。

于 2012-08-05T06:45:18.133 に答える
1

Tristan Reid（ビジネスロジックのラッピング）に同意します。実際、数ヶ月前に同じ問題に直面しましたが、偶然にも「The Art Of UnixProgramming」（オンラインで無料で入手可能）という本を発見しました。私の注意を引いたのは、ポリシーをメカニズムから分離するという哲学（つまり、インターフェースをエンジンから分離すること）でした。NETプラットフォームなどの最新のプログラミング環境では、すべてを1つのドメインに統合しようとしています。当時、私は次の要件を満たさなければならないWEBアプリケーションの開発を求められました。

  1. コアアルゴリズムを変更することなく、ユーザーインターフェイスの将来のトレンドに簡単に適応させる必要がありました。

  2. Web、コマンドライン、デスクトップGUIなどのさまざまなインターフェイスからアクセスできる必要がありました。

  3. WindowsとLinuxで実行する必要がありました。

メカニズム（エンジン）を完全にC / C ++で開発し、ネイティブOSライブラリ（POSIXまたはWinAPI）と優れたオープンソースライブラリ（postgresql、xmlなど）を使用することに賭けます。エンジンモジュールをコマンドラインプログラムとして開発し、最終的に2つのインターフェイスを実装しました。Web（PHP + JQueryフレームワークを使用）とデスクトップ（NETフレームワーク）です。どちらのインターフェースもメカニズムとは何の関係もありませんでした。WindowsのCreateProcess（）やUNIXのfork（）などの関数を呼び出してコアモジュールの実行可能ファイルを起動し、パイプを使用してプロセスを監視しました。

UNIXプログラミング哲学がすべての目的に適していると言っているわけではありませんが、それ以降はそれを適用して良い結果が得られ、おそらくそれはあなたにも役立つでしょう。メカニズムを実装するための言語を選択してから、インターフェイス設計を容易にする別の言語を使用します。

于 2012-08-04T00:08:18.313 に答える
0

UML モデラーなどのツールを使用してこれらのデータ構造をモデル化し (3 つすべてのコードを生成できる Enterprise Architect が思い浮かびます)、モデルから直接各言語のコードを生成できます。

XSDの使用に関する以前のコメントを詳しく見ていきますが。

于 2012-08-03T23:23:35.940 に答える
0

ドメイン エンティティに関するある種のメタ情報 (複雑さに応じて XML または DSL) を使用してそれを達成し、各言語のコード生成に進みます。これにより、(手動での) コードの重複を減らすことができます。

于 2012-08-04T09:31:30.257 に答える
0

ビジネス ロジックを Web サービスとしてラップし、3 つのすべての言語から呼び出すことができます (単一の実装のみ)。

于 2012-08-03T21:04:20.827 に答える