現在、SOA 内のフロントエンド ソリューションに取り組んでおり、ドメイン オブジェクトを保存するときに問題が発生しています。
バックエンドは、全体としても保存されるかなり大きなドメイン オブジェクトを提供します。反対側のフロントエンドは、このデータを複数のページとサブページに分割します。
実際の問題を共有する前に、いくつかの背景情報を提供したいと思います。
システムのほとんどのタスクは、プロセス エンジン、Web サービスとの通信、およびルール エンジンを使用して自動化されています。フロントエンドは、入力データが正しくなく、人がそれを修正する必要がある場合にのみ必要です。フロントエンドでの入力は Web サービスによって保存され、ユーザーがすべてが正しいと判断すると、ドメイン オブジェクトをプロセス エンジンに戻します。
今後の問題の簡単な例
Domain-Object (基本的にルートエンティティ)
- ページ A に表示されるエンティティ 1 (およびルートエンティティのいくつかのフィールド)
- ページ B に表示されるエンティティ 2
このプロセスでは、各エンティティのエラーを特定してマークします。ユーザーにタスクが与えられ、フロントエンドがドメイン オブジェクトをロードし、ページ A を表示します。ユーザーはフィールドを修正し、ページ B に移動したときに入力を保存して、すでに行った作業が失われないようにする必要があります。
問題：
エンティティ 2 にはまだエラーがあるため、ドメイン オブジェクトの保存を担当する Web サービスは ValidationException をスローします。そもそも、誤ったデータがどのように保存されたのか疑問に思われるかもしれません。Web サービスは、「自動」と呼ばれる保存サービスと「手動」と呼ばれる保存サービスの 2 つを公開します。プロセス エンジンは、返されるエラーごとにマーカーを作成するため、automaticSave 操作では無効なデータが許可されます。manualSave は現在、エラーを許容しません。
この問題に対処する方法のアドバイスを探しています。
これは、SOA 内ではかなり一般的な問題だと思います。間違っていたら訂正してください:-)
1 つの方法は、フロントエンドのデータがセッションにのみ保存され、ユーザーが永続化する前にすべてのエラーを修正する必要があるというものですが、使いやすさに関しては、それは最善のアイデアではないと思います。
別のアイデアは、バックエンドでの部分的な検証かもしれませんが、これにより、誤ったデータが入力される可能性があります
私の最後のアイデアは、プロセスエンジンによってマークされたエラーを manualSave に渡して、Web サービスが「ねえ、このフィールドには以前にエラーがあったので、これだけが無効な場合は ValidationException をスローしない」ことを認識させることでした。
あなたのアイデアをお待ちしています。
[更新] 最初の回答の後、ドメイン オブジェクトの構造を更新しました。この質問は、「優れたWebサービスを設計する方法」に拡張できるようです:-)