私は一般的な開発戦略を学んでいますが、それらについて多くの疑問が頭の中にあります。そのうちの 1 つは、依存関係を持たないアプリケーション レイヤーの作成に関するものです。プレゼンテーション レイヤー。たとえば、MVC アプリケーションでは、アプリケーション サービスがあるとしますが、このアプリケーション サービスは、プレゼンテーション層からの受信データ モデルの検証をチェックしません。これは、ASP.NET MVC 検証を介してコントローラーでのみチェックされます。サービス層には、内部に承認要素が含まれていません。すべての作業はプレゼンテーション層で行われます。それは正しいアーキテクチャだと思いますか？サービス層内にすべての検証と承認を再度含める必要がありますか? はいと言ったらどうやって？
サービス層に承認を含めるにはどうすればよいですか? サービスレイヤー内で認証を制御する方法が本当にわかりません。サービスレイヤーでも検証を複製しても問題ありませんか?
結局のところ、プレゼンテーション層が変わらないと確信している場合、そのようなデザインを作成する価値はありますか?
検証はドメイン層で行う必要があります。DDD アプリケーションでは、ドメイン (ビジネス) 層が検証を所有する必要があります。サービス層はドメイン上で動作し、ドメイン層によって発生した検証エラーを含むエラーを処理する必要があります。この場合のエラー処理は、サービス レイヤーの例外でラップし、エラー コードを返したり、エラーをログに記録したりすることを意味します。承認もサービス レイヤーの責任である必要があります。これは、プレゼンテーション レイヤー (ASP.NET MVC) が検証または承認の検証を実行する必要がないということではありません。通常、プレゼンテーション レイヤーでの検証は、ドメインおよびサービス レイヤーでの検証よりも軽量であり、ユーザー エクスペリエンスを向上させるために行われます。結局のところ、ほとんどの検証をクライアント側で実行できれば、それをして、サービスレイヤーへの旅行を保存してみませんか? 認可にも同じロジックが適用されます。
検証ロジックの重複に関しては、すべてのケースを満たす解決策はなく、全体的な複雑さを軽減して保守性を向上させるために、多少の重複を受け入れる必要がある場合があります。ドメイン層で検証を行う最も簡単な方法は、標準のガードを使用して ArgumentException インスタンスをスローすることです。ASP.NET MVC で検証を行う最も簡単な方法は、データ注釈属性を使用することです。多くの場合、すべてを網羅する検証システムを実装するよりも、検証ロジックをある程度複製する方が簡単です。さらに、ドメイン層によってのみ実行できる検証が存在する可能性があります。これは、それらを分離しておくための別の議論です。
サービス レイヤーでの承認はさまざまな方法で行うことができ、使用される基盤となるテクノロジによって異なります。WCF を使用する場合、承認を行うためのガイドラインが多数あります。