現在 mvc 開発フレームワークを使用している場合、ユーザー フロントエンドでユーザーが入力したテキストの正当性をチェックするとき、ユーザーが送信するとき、これは c 層または m 層で処理されるべきですか?
私は Yi Wei の意見に同意する必要があります。V はユーザー エクスペリエンスを保証するために検証されており、ユーザーが送信後にエラーを見つけて修正するために使用されます。データ自体の検証 (データがユーザーに属しているかどうか、データのステータスの変更が論理的な要件を満たしているかどうか)、M はデータの存在を確認するためにトランザクションを実行します。データが存在しない場合は、以下の手順を実行する必要はありません。 、それは異常なはずです。
この質問は、特定のアプリケーション、特定の言語、特定のフレームワークと組み合わせて分析する必要があり、チーム メンバーのスタイルや構成にも関係します。
個人的には、M が検証ロジックを実行して例外をスローし、それから C がそれをキャプチャしてフロントエンドが出力に必要な形式に変換することを好みます。この初期コードは少し冗長かもしれませんが、論理的な整合性とその後の拡張にとってはより有益です。
もう 1 つのアプローチは、検証ロジックとビジネス ロジックの一部を処理するために、M と C の間にいわゆるロジック層を確立することです
一般に、MVC フレームワークでは、ビジネス処理に基づいてサービス層が追加され、モデルは ORM マッピングされるか、直接破棄され、DAO が作成されます。次に、検証がどの層で行われるかについて説明します。メソッドはコントローラーです。レイヤー C とサービスレイヤー S の両方を実行する必要があります。Web サイトが開発されると、サービスをリモート呼び出し用のパブリック サービス コンポーネントとして分離する必要があるため、コントローラー レイヤーで検証を行わない場合は、データリクエストの場合、データに問題がある場合はパブリックサービスに直接送信し、エラーを返します。したがって、コントローラレベルでデータ検証を行っている場合、これは明らかにネットワークIOを無駄にします。 、データが正しくない場合は、直接例外をスローします。RPC を介してリモート呼び出しを行う必要はありません
これは状況によって異なります:
太ったモデル、細いコントローラー
Echang コーディングには原則があります: インターフェイスは相互に信頼しません。
フレームワークを使わずに自分で書く場合は、C層に属する必要があります。ただし、より多くのフレームワークが m 層に配置される傾向があります。
さらに、v レイヤーでのみ入力検証を実行しないでください。フロントエンドのものは簡単にバイパスされる可能性があるため、セキュリティ上のリスクが生じます。
各レイヤーは異なる重点を置いて実行する必要があります。
通常、MVC の C-M の間にサービス層を追加します (ただし、C または M の一部として理解することもできます)。この層はビューとコントローラーから切り離されるように設計されており、独立して外部に取り出すことができます。 API）。
それで、 ビューで、単一の値の比較的弱い合法性チェックを実行します コントローラーで、外部リクエスト パケットの正当性を確認し、いくつかのユーザー インターフェイスの権限を確認します。 サービスで厳密なデータ合法性検証、ビジネス ロジック制約検証、およびユーザー データ権限検証を実行します。 モデル内のデータの物理的合法性検証を実行します。
被験者が Python の Django や Flask などのフレームワークを使用したことがある場合は、Form クラスもあることに気づくでしょう。ユーザー コンテンツ検証のロジックは通常、Form クラスで実行されます。異なる状況に応じて、同じデータ モデルに対して異なる検証ルールを作成する必要がある場合があるためです。もちろん、Django はモデル層の検証もサポートしています。相対的に言えば。フォーム層は、より低い結合度でこれを行います。
単純な MVC は通常、モデル層で FORM 検証を行いますが、より成熟したソリューションは通常、FORM 層を持ち、構造的にはモデル層に統合されています。関数の実装はモデル層とは何の関係もないようです。
実際、合法性チェックもローカル側とサーバー側に分かれています。 たとえば、入力が空の場合は V レイヤーでチェックされ、入力形式が正しくない場合は M レイヤーでチェックされます。 適格であるかどうかをさらに確認したい場合は、M 層に配置され、サーバーにアクセスして確認されます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
私は Yi Wei の意見に同意する必要があります。V はユーザー エクスペリエンスを保証するために検証されており、ユーザーが送信後にエラーを見つけて修正するために使用されます。データ自体の検証 (データがユーザーに属しているかどうか、データのステータスの変更が論理的な要件を満たしているかどうか)、M はデータの存在を確認するためにトランザクションを実行します。データが存在しない場合は、以下の手順を実行する必要はありません。 、それは異常なはずです。
この質問は、特定のアプリケーション、特定の言語、特定のフレームワークと組み合わせて分析する必要があり、チーム メンバーのスタイルや構成にも関係します。
個人的には、M が検証ロジックを実行して例外をスローし、それから C がそれをキャプチャしてフロントエンドが出力に必要な形式に変換することを好みます。この初期コードは少し冗長かもしれませんが、論理的な整合性とその後の拡張にとってはより有益です。
もう 1 つのアプローチは、検証ロジックとビジネス ロジックの一部を処理するために、M と C の間にいわゆるロジック層を確立することです
一般に、MVC フレームワークでは、ビジネス処理に基づいてサービス層が追加され、モデルは ORM マッピングされるか、直接破棄され、DAO が作成されます。次に、検証がどの層で行われるかについて説明します。メソッドはコントローラーです。レイヤー C とサービスレイヤー S の両方を実行する必要があります。Web サイトが開発されると、サービスをリモート呼び出し用のパブリック サービス コンポーネントとして分離する必要があるため、コントローラー レイヤーで検証を行わない場合は、データリクエストの場合、データに問題がある場合はパブリックサービスに直接送信し、エラーを返します。したがって、コントローラレベルでデータ検証を行っている場合、これは明らかにネットワークIOを無駄にします。 、データが正しくない場合は、直接例外をスローします。RPC を介してリモート呼び出しを行う必要はありません
これは状況によって異なります:
太ったモデル、細いコントローラー
Echang コーディングには原則があります: インターフェイスは相互に信頼しません。
フレームワークを使わずに自分で書く場合は、C層に属する必要があります。ただし、より多くのフレームワークが m 層に配置される傾向があります。
さらに、v レイヤーでのみ入力検証を実行しないでください。フロントエンドのものは簡単にバイパスされる可能性があるため、セキュリティ上のリスクが生じます。
各レイヤーは異なる重点を置いて実行する必要があります。
通常、MVC の C-M の間にサービス層を追加します (ただし、C または M の一部として理解することもできます)。この層はビューとコントローラーから切り離されるように設計されており、独立して外部に取り出すことができます。 API）。
それで、
ビューで、単一の値の比較的弱い合法性チェックを実行します
コントローラーで、外部リクエスト パケットの正当性を確認し、いくつかのユーザー インターフェイスの権限を確認します。 サービスで厳密なデータ合法性検証、ビジネス ロジック制約検証、およびユーザー データ権限検証を実行します。 モデル内のデータの物理的合法性検証を実行します。
被験者が Python の Django や Flask などのフレームワークを使用したことがある場合は、Form クラスもあることに気づくでしょう。ユーザー コンテンツ検証のロジックは通常、Form クラスで実行されます。異なる状況に応じて、同じデータ モデルに対して異なる検証ルールを作成する必要がある場合があるためです。もちろん、Django はモデル層の検証もサポートしています。相対的に言えば。フォーム層は、より低い結合度でこれを行います。
単純な MVC は通常、モデル層で FORM 検証を行いますが、より成熟したソリューションは通常、FORM 層を持ち、構造的にはモデル層に統合されています。関数の実装はモデル層とは何の関係もないようです。
実際、合法性チェックもローカル側とサーバー側に分かれています。
たとえば、入力が空の場合は V レイヤーでチェックされ、入力形式が正しくない場合は M レイヤーでチェックされます。
適格であるかどうかをさらに確認したい場合は、M 層に配置され、サーバーにアクセスして確認されます。