1

Spring SimpleFormController で Business Objects を formBackingObjects として使用するための設計上の問題。

コントローラーの役割は、エンド ユーザーが新しいビジネス オブジェクトを Web アプリケーションに追加できるようにすることです。

したがって、formBackingObject(HttpServletRequest request) メソッドを介してビジネス オブジェクトを渡します。しかし、私たちは難問にぶつかりました。

新しいビジネス オブジェクトを作成するために使用しているファクトリでは、一部の属性を null にすることはできないというビジネス ルールが適用されます。しかし、エンド ユーザーが何を入力したいのかがわからないため、「必要な名前を入力してください」などの「合理的なデフォルト」を渡してきましたが、それはせいぜいハック/イッキーに思えます。

開発者は何をすべきか? これは古典的な鶏卵問題のように感じます。

すべてのビジネス オブジェクトはインターフェイスに基づいています。ビジネス オブジェクトを表すスタブを作成し、スタブを formBackingObject として渡し、フォーム送信時にスタブをファクトリに渡す必要がありますか? それとも、formBackingObject に何も渡さずに、リクエストから送信された情報を手動で収集する必要がありますか?

他の合理的なアイデア/パターンはありますか?

お時間をいただきありがとうございます。

4

2 に答える 2

2

formBackingObject を使用せず、手動で情報を収集するという選択肢は絶対に選択しません。そうすると、そもそも Spring MVC の価値を高める多くの機能が失われてしまいます。

私があなたなら、「初期化されていない」ビジネス オブジェクトを作成するために特別に設計された新しいファクトリまたはファクトリ メソッドを作成し、それを formBackingObject として使用します。

広く使用されているもう 1 つの方法は、ビジネス オブジェクトを formBackingObject として使用するのではなく、formBackingObject にすることのみを目的とする別のトランスポート オブジェクトを作成することです (そして、ビジネス オブジェクトのファクトリ メソッドを追加して、トランスポート オブジェクト)。これの大きな利点の 1 つは、ビジネス オブジェクトの内部に他のオブジェクトの深いツリーがある場合、formBackingObject として使用するのが面倒になる可能性があることです。formBackingObject として使用するためだけに個別のトランスポート オブジェクトを作成すると、よりフラットな構造にすることができます。

于 2009-11-11T19:09:05.300 に答える
1

コマンド オブジェクト (単純な POJO) を使用して、コントローラーへのユーザーの入力を表します。次に、Spring MVC に組み込まれている検証を使用して、すべての必須フィールドがコマンド オブジェクトで提供されていることを確認できます。コマンドが検証に合格した場合は、プログラムで (またはDozerなどの Bean マッピング ライブラリを使用して) 「ビジネス オブジェクト」にマップできます。

このようにして、既存のビジネス ロジック/ルール/サービス クラスに触れたり変更したりすることなく、検証、不完全なユーザー送信などを処理できます。これにより、Web レイヤーをこれらの既存のレイヤーから分離しておくことができます。

参考までに、パート 4で検証オブジェクトとコマンド オブジェクトについて触れている MVC チュートリアルを参照してください。

于 2009-11-11T19:10:01.550 に答える