私のWebアプリでは、すべてのロジック（登録など）を担当するサービスレイヤーがあります。フォームにサーバー側の検証を実装したいと考えていました。問題は、無効なデータをキャッチするたびに例外をスローすることはできません。ユーザーが間違った電子メールとパスワードを入力した場合、サービスメソッドは電子メールをチェックするとすぐに例外をスローし、パスワードエラーはユーザーの後にのみ通知されるためです。メールを修正し、フォームを再送信しました。フォーム全体を一度に検証したい。重要なことは、エラーの種類を渡すだけでよく、コントローラーの ModelState に表示メッセージを追加する必要があることです。私にはいくつかのアイデアがあり、パフォーマンスと優れた実践の観点からどちらが優れているかを判断するのを手伝ってもらいたいです (ないかもしれません-私が投稿したすべてよりも優れた別のソリューションがあるかもしれません)。
アイデア:
- エラーをディクショナリに収集し、キーと値の形式ですべてのモデル エラーを含む単一の例外をスローします (例: "パスワード"、"記号が 5 つ以上ある必要があります")。コントローラーでエラーをキャッチし、switch() を使用してすべてのエントリを読み取り、エラーの種類を検出して ModelState に適切なメッセージを追加します。
- 長所: 組み込みの Exception.Data ディクショナリを使用します
- 短所: 文字列からエラーの種類を解読する必要がある
- 前と同様ですが、追加のフィールド列挙辞書 (例: "Password"、ValidationEnum.LessThanFiveSignsError) を持つカスタム例外クラスを作成します。
- 長所: 列挙型は switch() 操作のより洗練されたソリューションです
- 短所: 組み込みの例外クラスが実際に実行できることを実行するには、カスタム例外を実装する必要があります
- 辞書を使用したカスタム例外ですが、列挙型ではなく例外があります - StringTooShortException や UsernameAlreadyExistsException などのクラスを作成し、それらを辞書に追加します (例: "Password"、new StringTooShortException())。スイッチはおそらく型オブジェクトをチェックする必要があります...
- 長所：例外を使用しますか？考えれば考えるほど、これは良い考えではないと思います...
- 短所: オブジェクトを Exception サブクラスに渡し (すべての Exception クラスの属性などを含む)、そのオブジェクトがどのタイプの情報のみを使用しますか?
- すべてのサービス メソッドが、{object regularReturnValueDependingOnMethod, MyCustomErrorContainer canBeListOfEnumsOrSomething} を含むカスタム クラスを返すようにします。このアイデアと以前のアイデアの基本的な違いは、エラー コンテナーをコントローラーまで運ぶためだけに例外をスローしないことです。適切なワークフローを使用します。
- 長所：例外をスローせず、コントローラーに検証エラーを返すだけで、適切なワークフローを使用して値を渡します
- 短所: 検証エラーをコントローラーに返すためだけに、すべてのメソッドの戻り値をラップするのは多すぎませんか? おそらく検証エラーはまさにそのような状況であり、例外を使用してコントローラーにメッセージを送信する必要があります (そのメッセージが何であれ: テキスト文字列、またはこの場合はオブジェクト全体)
- 戻り値をラップせず、コントローラーで検証エラー コンテナーを作成し、それを "out" パラメーターとしてサービスに渡します。
- 長所：シンプル
- 短所: サービス メソッドを呼び出す前に、エラー コンテナー インスタンスを作成する必要があります (入力を検証するものだけです)。エレガントですか？
どう思いますか？どれが一番いいですか？ただやり遂げることには興味がない。あるべき姿でやり遂げたい。私は良いプログラミングの振る舞いを学びたい:)
助けてくれてありがとう:)
//編集: 私の最新の考え: 検証目的のためだけに別のサービス メソッドを作成することができます (例: メソッド: 登録用の RegisterUser() とモデル検証用の ValidateRegisterUser() の前に検証メソッドを呼び出すようにする必要があります)。通常のメソッドを呼び出します。どう思いますか?