私はこのようなアーキテクチャを考案します - アプリケーションはモジュールとモジュールで構成され、ドメイン固有のユーティリティを使用してモデルやデータベースを変更します。データの検証に責任があるのはどの層ですか
例として、フォームを表示し、入力を受け入れ、ユーザー情報を挿入するための呼び出しを実行する登録ユーティリティを使用する登録モジュールがDBを実行します。誰がデータ検証を実行する責任がありますか？
1）モジュール、それはユーティリティ 2までのデータを渡して「優れた」そのまま）ユーティリティ、何も疑わしいデータが今まで 3を介して取得しないでしょう。この方法）の両方が徹底したデータの検証 4を持っている必要があります）一部他の手配
思考？意見ですか？
データを使用しているコンポーネントは、それ自身の目的でデータを検証する責任があります。
例：サービス層の一部は、入力フィールドが有効な電子メールアドレスであることを検証することがあります。これは、それがビジネスルールによって決定されるためです。データ・レイヤーは、データが特定の長さよりも長くないことを検証することができますが、それはデータベース列に収まる最大サイズですが、電子メール・アドレスかどうかは特に気にしません。
また、再利用が可能な場所に設置する必要があります。したがって、（MVCで）上記の「有効な電子メール」の検証は、複数のコントローラ/ビューでそのビジネスロジックへの入力が発生する可能性があるため、コントローラまたはビューには入りません。検証ロジック。
検証は可能な限りモデルに近いものにする必要があります。ユーティリティはモデルを変更するので、データモジュールの有効性を信用すべきではありません。これにより、ユーティリティを再利用する方が安全です（検証コードをコピーせずに複数のモジュールで使用できます）。
一方、モジュールに検証を置くと、ユーザーに近い方がより良い経験を得ることができます（より高速なクライアント側の検証など）。 私の意見では、モジュール内に別の検証レイヤーを追加することで、ユーザーエクスペリエンスを向上させるリソースがあれば、あなたのユーティリティーに検証を置くことをお勧めします。
データは、できるだけ早く検証する必要があります。つまり、データを入力（ユーザー入力など）から読み取ってから検証するまでの距離は最小限にする必要があります。実用的な理由は、検証コードを見直すことが容易になるからです。
MVCでは、コントローラーがすべての入力値を読み取る場所であると仮定して、コントローラーに移動する必要があります（コントローラは、このようにしたときに、コントローラーが検証済みの値をモデルに渡します）。 ）。
つまり、検証コードにはかなりの量のものが共有され、検証のためにヘルパーコードを書くことができます。
検証のための場所は、アプリケーション内のAPIの露出と、設計のどこで検証が行われるべきか（つまり、検証の対象者は誰か）によって異なります。
有効な電子メールアドレスを設定するには、他のすべてのコードが有効な電子メールアドレスを期待しているため、データを受け入れるコントローラーがそれを実行する必要があります。一方、データベース処理のためにデータが適切にエスケープされているかどうかの検証は、実際のSQL処理の真上で、モデルの真ん中にあります。