8

ドメイン モデル パターン、DDD、およびその他の多くの設計パターンを利用するアプリケーションがあるとします。以下に示すように、いくつかのソリューションがあるとします。

  • ソリューション.モデル
  • Solution.Repository
  • ソリューション.サービス
  • Solution.Presentation
  • ソリューション.UI.Web

ユーザー エクスペリエンス レイヤーは Solution.UI.Web であり、ASP.NET WebForms アプリケーションであると仮定します。クライアント側の検証をどのように実施しますか?

考慮すべき点がいくつかあります。

何よりもまず、検証エラーをクライアントに返すためにアプリケーション/データベース サーバーにアクセスする必要はありません。ただし、サーバー側の検証も実装できますが、クライアント側の検証も必要になります。 .

次に、ユーザー エクスペリエンス レイヤーに検証ルールを実装したくありません。これは、アプリケーションが WebApp であり、WinApp クライアントも作成することにした場合、検証ルールをもう一度実装する必要があるためです --> メンテナンスの悪夢です。

簡単な方法の 1 つは、ViewModel オブジェクト (クライアントに送信されるドメイン エンティティのフラット化されたビュー) を使用して検証ロジックを実装し、アプリケーション/データベース サーバーにアクセスする前にそれらのオブジェクトを検証することです。

さまざまなアプリケーションで何度も使用されている別のアプローチは、検証エラー メッセージのコレクションを生成し、そのコレクションをクライアントに送信するというものです。それは問題ありませんが、問題があります。特に大きなデータ入力フォームがある場合は、検証エラーの簡単な要約メッセージだけでは不十分です。

現在、ASP.NET MVC フレームワークにより、作業がはるかに簡単になります。EF + DataAnnotations を使用でき、MVC Scaffolding フレームワークがほとんどの作業を実行できます。ただし、MVC アプリケーションを作成し、jQuery と JavaScript を使用して検証ロジックを実装する場合は、これが当てはまります。

しかし、WinForms や WebForms など、さまざまなアプリケーションで利用および使用できる検証フレームワークを実装するための、より一般的なアプローチが必要な場合はどうでしょうか?

明確にするために、私が探しているのは、ドメインモデルで実装してクライアントアプリケーションに適用できる検証フレームワークを実装するための一連の設計パターン/原則および/または手法/フレームワークです。そして、壊れたルールなどに関する文字列エラー メッセージのコレクションを返すだけではなく、検証の失敗時にデータ バインドされたコントロール (TextBox、ComboBox、DateTimePicker など) を更新できるようにしたいと考えています。ユーザーエクスペリエンスレイヤーはより直感的になります（そうする場合）。

私はあちこちでいくつかの実装とフレームワークを見てきました.ASP.NET MVCクライアント側の検証をしばらく使用していたので、私の答えはMVCやJavaScriptの検証とは何の関係もありません.

4

3 に答える 3

5

DDD では、ドメインは通常自己検証型です。つまり、オブジェクトを無効な状態にすることはできません。ここでは値オブジェクトが大いに役立ちます。それらは単にフォーマット規則をカプセル化します。たとえば、常に整形式であることが保証されているクラスZipCodeを持つことができます。追加の責任として、ZipCode.TryParseやZipCode.Validateなどの静的メソッドを持つことができますこれは、任意の文字列をパラメーターとして受け取り、検証します。このようにして、検証ロジックが 1 か所に集中します。ドメイン オブジェクトが UI から直接アクセスできる場合は、このロジックを他の場所に複製する必要はありません。これは、ファット クライアント (Windows フォーム、WPF) の場合です。残念ながら、サーバーへのラウンドトリップなしで検証を実行する必要がある場合、Web クライアントの重複を回避する方法はありません。

于 2011-08-11T01:55:10.030 に答える
3

私は、包括的な検証ソリューションに出くわしたことはありません。この理由の 1 つは、検証ロジックがアプリケーション層によって微妙に異なる可能性があることです。たとえば、ドメイン層によって適用されるすべてのルールをクライアント側で適用できるわけではないため、クライアント側の検証に合格する可能性があるにもかかわらず、ドメイン層から伝播された検証メッセージを表示する必要がある場合が常にあります。

ただし、ASP.NET MVC の検証モデルは拡張可能であり、追加の検証ルールをサポートするように拡張したり、DataAnnotations 以外の検証フレームワークをイベント化したりすることができます。Enterprise Library Validation ブロックを ASP.NET MVC と統合する例を次に示しますが、記事で指摘されているように、クライアント側の検証は実装されていません。もう 1 つの方法は、ドメイン層で DataAnnotations 属性を使用することです。DataAnnotations 名前空間は、ASP.NET MVC に関連付けられていません。

ただし、これらのアプローチの課題は、検証ルールをドメイン オブジェクトからビュー モデルに伝播することです。理論的には、AutoMapperを拡張して、ドメイン モデルの検証ルールをビュー モデル クラスに引き継ぐことができますが、実装とメンテナンスのコストがこのソリューションのメリットを上回る可能性があります。

Fluent Validationフレームワークは、包括的な検証ソリューションの出発点として使用できます。ASP.NET MVC でこのフレームワークを使用する例は多数あります。

于 2011-08-07T22:18:03.137 に答える