それは、デザインとアーキテクチャの問題です。
古いシステム用の新しい UI レイヤーを開発しています。このシステムは、特定の xml 形式のリクエストを受け付けます。現在、新しい UI レイヤーからの要求は、コントローラーを介してデータ マッサージ クラスに送られます。
これTranslator/Massaging class
により、UI リクエスト xml が目的のリクエスト形式に変換されます。UI レイヤーから受け取った XML に、非推奨の要素と定数をいくつか追加します。
UI からの要求 XML は、実際のバックエンドと部分的に似ています。ただし、Translator/Massaging
実際のリクエストに変換するには、クラスに移動する必要があります。
私の質問は、リクエスト XML が実際のリクエストと部分的に類似している場合、UI レイヤーが心配する必要がありますか? UIレイヤーはデータをJSON形式で送信し、トランスレーターTranslator/Massaging
クラスはそれを実際のリクエストxmlに変換できますか?
3 に答える
私の質問は、リクエスト XML が実際のリクエストと部分的に類似している場合、UI レイヤーが心配する必要がありますか?
次の質問で示唆されたように、メッセージング クラスは GUI データを実際の XML 要求に変換できます。
UI レイヤーは JSON 形式のデータをメッセージング クラスに送信するだけで、メッセージング クラスはそれを実際の要求 XML に変換できますか?
出来た。ただし、GUI にはデータ モデルが必要です。GUI はデータ モデルと対話します。データ モデルは、メッセージング クラスと対話します。あなたが私たちに伝えていない要件がない限り、別のデータ形式は必要ありません。
私の質問は、リクエスト XML が実際のリクエストと部分的に類似している場合、UI レイヤーが心配する必要がありますか? UIレイヤーはJSON形式のデータをマッサージクラスに送信するだけで、マッサージクラスはそれを実際のリクエストxmlに変換できますか?
明らかにそれができます。しかし、それは「マッサージ」クラスがやるべきことがもっとあることを意味します.
私の考えでは、ここで間違った質問をしている可能性があります。私があなたの立場だったら、なぜ「古い」システムのリクエスト形式を直接使用できないのか、または「新しい」システムでリクエストを受け入れるように「古い」システムを変更できないのか、自問自答するでしょう。直接フォーマットします。
別の言い方をすれば、新しいフォーマットを実装する目的は何なのか、すべての余分なコーディングと「マッサージ」のパフォーマンスへの影響を自問してください。
あなたが私たちに話していないことが他に起こっていない限り、これは私には少し不必要に思えます.
サービスを考えよう!サーバーが提供し、クライアントが使用する機能は、サービス インターフェイスによって抽象化する必要があります。これにより、このサービスを使用するコードは、その実装や関連するプロトコルについて心配する必要がなくなります。次に、サーバーに実際の実装を行い、クライアントにリモート ファサードを実装します。これにより、リクエストがサーバーに転送され、応答も処理されます。
interface SomeService {
public SomeResult doSomething(SomeArguments) throws SomeException;
}
class SomeServiceServerImpl implements SomeService {
// server-side implementation
}
class SomeServiceClientFacade implements SomeService {
// client-side facade, forwards the request, for example to a web service
}
その後、ファサードは引数を XML に変換し、Web サービスを呼び出し、XML 応答を解析して、それを結果オブジェクトまたは例外に戻すことができます。
標準化されたRPC (リモート プロシージャ コール) プロトコル(SOAP やJSON-RPCなど) を使用する場合、これを処理する最も洗練された方法は、一般的な方法で要求のマーシャリングと応答のアンマーシャリングを行うProxyを使用することです。リモート サービス プロキシを安価に作成できます。InvocationHandler