2009-04-09 5 views
4

Springのフォームコントローラ(SimpleFormControllerまたはBaseCommandControllerなど)は、コマンドを使用してHTMLフォームとコントローラ間でデータを渡します。私の質問は、バッキングモデルをコマンド自体として使用するのが一般的なのでしょうか?あるいは、バッキングモデルの属性に対応する属性を持つ別々のコマンドを作成するのが一般的です。Springフォームコマンドの目的

私の問題は、文字列以外の属性の変換にプロパティエディタが必要であるということです。強く型付けされていない多数のカスタムフィールド型を持つデータモデルを想像してみてください。フォーム提出時に、プロパティエディタはバリデータが呼び出される前に変換を行います。型変換が不可能な場合(ユーザー入力エラー)、バリデーターは詳細なエラー・メッセージを提供する機会を得ることはありません。 HTMLフォームに表示されるのは、一般的なエラーメッセージです。私のrelated Stackoverflow questionを参照してください。

代わりに、バッキングモデルの各フィールドを複製する別のコマンドを作成し、文字列として作成することもできます。このようにして、バリデーターは各フィールドの文字列表現を検証できます。コントローラのonSubmitは、テキストベースのコマンドをバッキングモデルに変換します。 Springの私の研究から、これは意図された使用法のようです。この道を迷う私の躊躇は、データモデルごとに別々のコマンドを作成する必要がある厄介な方法です。次に、コマンドとデータモデルをマーシャリングする作業が追加されました。フォームでバッキングモデルを直接編集し、プロパティエディタを使用して変換を行う方がずっと便利です。問題は次に検証です。

私は他の人がカスタム型の非文字列フィールドを含むモデルのフォームベースの編集の問題にどのように近づいているのか不思議です。

答えて

3

Spring binding and validation APIを調べることをおすすめします。サービスレイヤーが必要とするオブジェクトにフォーム要素をバインドし、コントローラーに渡します。

私の好みは、ビジネス層に直接バインドし、Web層のためだけにDTOを作成しないことです。私は並行階層を気に入らない。

2

IMHOは、あなたのドメインクラスをどのように設計したいかにまでこだわっています。私は、不適切な値などを設定することさえ許さないことによって、qiute strictを設計する方が好きです。これは、Springがバインディングと検証を処理する方法と非常によく似ていません。

ドメインモデルが弱体化するのを避けたいのですが、私は通常、プレゼンテーションがドメインオブジェクトに対して少し異なるビューを取得するため、DTOをコマンドオブジェクトとして使用する傾向があります。典型的な例は、パスワードを運ぶUserドメインクラスです。プレゼンテーション層では、通常、実際のユーザーにパスワードを2回入力させ、検証ステップでそれらの値を比較する必要があります。一致した場合にのみ、データはドメインクラスにバインドされます。

少しのオーバーヘッドが発生する可能性がありますが、ドメイン/アプリケーション層を完全に分離することができます。