メッセージキューからメッセージを取得し、データベース内のテーブルを更新するコードを作成する必要がある場合、どのようにすればよい方法でメッセージを構造化できますか。どのように構成しますか?メッセージはXMLデータであり、テーブルの行ごとに1つのノードです。テーブルの行は、更新、削除、または挿入される可能性があります。
3 に答える
あなたが良い答えを出すのに十分な情報を提供してくれたとは思いません。メッセージはどのように見えますか?それらは内容/タイプが異なりますか、それともすべて単なる「メッセージ」ですか?それらは互いに相互作用しますか、それともこれは単なるデータ形式の変換ですか?OO開発の鍵の1つは、「名詞と動詞を見つける」ゲーム(これはあなたが説明したのと同じくらいです)が最良の解決策につながることはめったにないことを理解することです。確かに最悪の事態にはなりませんが、データの集約と一連の手続き型コードが必要になります。
ただし、手続き型コードは悪くありません。なぜそれはOOである必要があるのですか?問題自体にポリモーフィズムとデータの隠蔽が必要ですか?モデル化しようとしている複雑な動作はありますか?問題が単純な場合、OO以外のソリューションを使用することに恥はありません。
通常、メッセージキューのOO実装では、個々のタイプのメッセージを表すクラスを自分で作成します。取得することが期待されるさまざまなメッセージタイプが相互に派生している限り、これによりメッセージのクラス階層が提供されます。
構成ベースの永続性フレームワークを使用すると、これらのクラスの永続性を直接設定できます。
次に、メッセージキューをリッスンし、メッセージを永続化するクラスが1つ以上あります。おそらく、1つだけです。それ以上に手の込んだものである必要はありません。
メッセージングを行ったり、あらゆる種類のミドルウェアを扱ったりするときに OO コードを作成する最善の方法は、ミドルウェア API をコードから隠して、ビジネス ロジックだけを扱うことです。
たとえば、これらの例を参照してください
- あなたが説明したほとんどのユースケースであるPOJO Consumingと
- メッセージ キューにメッセージを送信する必要がある場合は、POJO プロデュースを行います。
次に、データ転送オブジェクトがどのように見えるかを定義する必要があります。XML / JSON / なんでも、ネットワーク上でどのようにエンコードしたいか。
このアプローチの優れた点は、コードが完全にミドルウェアに依存しないことです。メッセージ キューを交換して、データベース、JavaSpace、インメモリ SEDA、ファイル、またはその他の通信プロトコルまたはミドルウェア API を使用できます。