0

私のプロジェクトには、リポジトリを操作するサービス レイヤーがあります。サービス層はコントローラーによって呼び出されます。

多くの場合、コントローラー レイヤーは、受信情報がシステムに取り込まれる前に検証できます。ただし、場合によっては、送信されたデータが有効でないためにエラーが発生することがありますが、これはサービス レイヤー内のポイントでのみ発生します。

それを念頭に置いて、ユーザー サインアップ フローを実行していると仮定しましょう。

  • 重複したユーザー名は許可されていません
  • ユーザー名を指定できます
    • ユーザー名が指定されていない場合は、姓名から生成されます

これは、(必要に応じて) 生成し、重複するユーザー名をチェックするプロセスがサービス層で発生することを意味します。

重複が発生した場合、呼び出し元に信号を送るための最も分離された理想的な方法は何ですか (コントローラー、バックグラウンド タスク、または別のサービスであっても) - それ:

  • ユーザー名フィールドに問題があります
  • 該当する場合、生成されたユーザー名

理想的には、提案されたアプローチを他のサービスで発生するエラーに適用できるようにして、一貫した方法で報告し、呼び出しレイヤーでエラーを処理できるようにすることができます。

4

2 に答える 2

2

私が通常行うことは、ビジネス/ドメイン/アプリケーション レイヤーのすべてで通常の .NET 例外をスローすることです (スタック トレースを保持します!)。これには、例外の内容に関する情報が含まれています。

サービス レイヤーでは、グローバル例外ハンドラーが例外をエラーに変換します (WCF サービスの場合)。また、その時点で内部を記録することもできます。

したがって、内部 (例外) は内部に保持されます。ただし、そのパブリック部分は、サービスのコンシューマーに自動的に公開されます。

通常、私FluentValidationはアプリケーション レイヤーとビジネス レイヤーで検証を行います。これにより、検証を特定の検証クラスに配置し、それらを再利用することもできます。

于 2014-08-13T13:25:33.457 に答える
1

私は@L-Threeの答えが好きですが、別の提案をしたいと思います.検証エラーをサービスレイヤーメソッドからの戻り結果の一部にします.

私の感覚では、ドメイン/サービス レイヤーがすべての検証を担当する必要があり、UI で行われる入力の検証はあれば便利だと思います。

于 2014-08-13T16:33:29.647 に答える