3

現在、ASP.NET MVC2 プロジェクトに取り組んでいます。実際の MVC Web アプリケーションに取り組むのはこれが初めてです。ASP.NET MVCの Web サイトのおかげで、すぐに使い始めることができましたが、データモデルの検証に関してはまだあいまいな知識しかありません。

私の問題は、複雑な検証ルールに関して、入力されたデータモデルをどこで管理すればよいか本当にわからないことです。たとえば、正規表現を使用して文字列フィールドを検証するのは非常に簡単で、フィールドを特定の属性で装飾するだけでよいことがわかっているため、データ管理ルールがモデルに実装されています。しかし、特定の時間ルールに従って正しく設定する必要がある複数の日時など、互いに検証する必要がある複数のフィールドがある場合、どこで検証する必要がありますか? 独自の検証属性を作成できることはわかっていますが、属性を使用して検証するには複雑すぎる特定の検証パスを検証で要求することがあります。

この最初の質問は、コントローラーでモデルを検証するのは正しいですか? という関連する質問にもつながります。現時点では、これが複雑な検証のために見つけた唯一の方法だからです。しかし、これは少し汚いと思います。コントローラーの役割に実際には適合せず、テストがはるかに難しいと感じています(複数のコードパス)。

ありがとう。

注意: ここでかなり良い解決策をいくつか得ましたが、他のアイデアや「ベスト プラクティス」の解決策を待っています。

4

3 に答える 3

4

メガデュープ。メガ主観。「どこで、どのように MVC で検証するか」という議論は、明確な答えを思い付くことなく打ち負かされました。これは各開発者/ショップにとって非常に主観的で哲学的なものであるため、全員が何かに同意することはほとんど不可能です.

もう 1 つの問題は、検証ツールにもさまざまな形やサイズがあり、さまざまなスコープやレイヤーで機能できることです。バリデーションツールの多様性は、ほとんど正気ではありません。if( someString != "" ) はどうしてそんなに難しくなったのですか? ;)

これらの他の回答を読むと、ベストプラクティスがまったくないことがすぐにわかります。ドメイン駆動設計の原則と、無効な状態とオブジェクトに関する議論に入ると、議論がさらに複雑になることがわかります。

検証はどこで行いますか?モデル、コントローラー、またはビュー

ドメイン エンティティの代わりに DTO を使用した ASP.NET MVC 2 の検証

ASP.Net MVC 2 の検証では、パターンと使用に関してもう少し考える必要がありますか?

ドメイン エンティティから DTO への検証属性のマッピング

ASP.NET MVC の検証ライブラリはどれですか?

ASP.NET MVC - ユーザー入力とサービス/リポジトリ - 検証を行う場所は?

ASP.NET MVC: データ注釈の検証は十分ですか?

MVC - フォーム検証を実装する場所 (サーバー側)?

Asp.Net MVC 検証

DDD:

ドメイン駆動設計での検証

于 2010-05-21T17:46:55.927 に答える
2

私の個人的な意見は、ビューをできるだけきれいに保ち、ビューにデータのみを表示するように強制することです(ビューをできるだけダムに保ちます)。

確かに、必須、正規表現ルールなどのビューでいくつかの簡単な検証を行うことができます。

複雑なビジネス ルールは、ビジネス エンティティまたは何らかのビジネス ロジック レイヤー内に配置する必要があります。

私が MVC プロジェクトで行っていることは、モデルに Validate() などのメソッドを呼び出してもらい、ビジネス ルールなどの検証の最終レベルをチェックしてから、Save() を呼び出すことができるようにすることです。

于 2010-05-21T12:12:23.023 に答える
1

検証の準備が整ったデータが入力されたクラスを取得したら、それをコントローラーの検証クラスに渡すだけです。

于 2010-05-21T12:18:56.157 に答える