矛盾がないことを保証したいはずです。データ型や書式まわりのバリデーションルールが適用されます。データが保存される前、ドメインまたはアプリケーションルールが適用されます。これらのルールはアプリケーションのデータの一貫性の保証に役立ちます。データのバリデーションではデータの型、形状およびサイズなどを確認することができます。既定ではリクエストデータがエンティティーに変換される前に検証が行われます。返されたエンティティーはエラーを含んだ状態になります。エラーのあるフィールドは返されたエンティティーには含まれません。エンティティー検証失敗。}バリデーションが有効になっている状態でエンティティーを構築すると、次のことが起こります:バリデータオブジェクトが作成されます。バリデーションプロバイダーが追加されます。命名に沿ったバリデーションメソッドが呼び出されます。validationDefault。イベントが発動します。リクエストデータが検証されます。リクエストデータがそのカラム型に対応する型に変換されます。エラーがエンティティーにセットされます。検証を通らなかったフィールドは除外されます。オプションに偽を指定してください。メソッドについても同じことが言えます。false]);既定のバリデーションセットの作成¶バリデーションルールは規約ではテーブルクラス中で定義されます。何のデータが検証されるかとあわせてどこで保存されるかも定義します。節に記載されています。注釈バリデーションオブジェクトは主にユーザー入力の検証用に意図されています。フォームやその他の投稿されたリクエストデータです。適用させたいバリデーションルールを選ぶこともできます。メソッドを呼び出します。メソッドが使用されます。記事テーブル用のバリデータの一例はこのようになります。}}必要に応じていくつものバリデーションセットを設けることができます。アソシエーションに異なるバリデーションセットを使用¶バリデーションセットはアソシエーションごとに定義することもできます。変換されるアソシエーション各々に追加のオプションを渡すことができます。その構築過程を複数の手順に分割することは簡単です。セット中で定義されているバリデーションルールも含むことになります。バリデーションプロバイダー¶バリデーションルールは既知のあらゆるプロバイダーで定義されている関数を使うことができます。プロバイダーではテーブルクラスまたはそのビヘイビアーのメソッドが有効です。プロバイダーとしてセットアップされます。バリデーションルールを作る時に、そのルールのプロバイダー名を指定できます。それをバリデーションルールとして使うことができます。}}バリデーションルールにはクロージャも使うことができます。'適切な値ではありません。}]);バリデーションメソッドは通らない時にエラーメッセージを返すことができます。これは渡された値に動的に基づくエラーメッセージを作るための簡単な方法です。名前を指定して結果のオブジェクトを取得できるようになります。インスタンスを受け取ります。プロパティーを使うことができます。基本的な検証が完了した後にのみ適用されるもっと複雑な検証も設けています。この種のルールはしばしば「ドメインルール」や「アプリケーションルール」と言われます。いくつかのドメインルールの例は次のようになります:メールアドレスの一意性の保証。(たとえば、請求書のステータス更新)。論理削除されたアイテムの更新の抑制。使用量/料金の上限の強制。メソッドを呼ぶとチェックされます。メソッドで定義されます。イベントを使うことができます。$rules;}ルールの関数はチェックされるエンティティーとオプションの配列を期待します。オプションはルールが追加されるテーブルクラスを含みます。受け取るので、インスタンス関数を使うこともできます。'uniqueEmail');または呼び出し可能なクラスも使えます。定義することができます。'この請求書はそのステータスに遷移できません。メソッドを呼ぶとエラーを確認できます。単純なルールクラスを内包しています。組み合わせはすでに使用されています。ルールでは列挙したフィールドのみが使われるのを覚えておくことが重要です。変更しても上記のルールは発動しないことを意味します。ルールのコードはより良いユーザーエクスペリエンスを提供するのに役立ちます。ルールクラスを内包しています。複合主キーに役立ちます。'Articles'));存在をチェックするための関連テーブルのフィールドは主キーの一部でなければなりません。通るように強制することができます。参照しますが、必須ではありません。あっても、このルールが通ることを許可します。値が存在することを許可します。値を含むことができます。中に1つだけで存在できます。ルールが利用できます。記事にタグは5つ以内。持てます'));ルールに基づく件数を定義する際、第3引数は、比較演算子を定義します。プロパティーの件数が範囲内であることを保証するために、2つのルールを使用してください。返すことに注意してください。場合、保存操作は失敗します。制約が失敗したときにユーザーフレンドリーなエラーメッセージを提供したい場合に使用できます。このルールを使用すると、アソシエーションが関連レコードを持っているかどうかを確認できます。更新時に各コメントが記事にリンクされていることを確認してください。削除時に記事にリンクされたコメントがないことを確認してください。'削除する前にコメントがない状態にしてください。'));エンティティーメソッドをルールとして使用¶ドメインルールとしてエンティティーのメソッドを使いたいかもしれません。'ruleName');条件付きルールの使用¶エンティティーデータに基づいて条件付きでルールを適用することができます。返された文字列はエラーメッセージとして使用されます。ルールから返されたエラーメッセージによって上書きされます。ことに注意してください。エンティティーにエラーメッセージが設定されません。再利用可能なカスタムルールの作成¶カスタムドメインルールを再利用したい事もあるでしょう。独自の呼び出し可能なルールを作成することによって行います。$rules;}そのようなルールを作成する方法の例として、コアのルールを確認してください。再利用可能なクラスにそうしたルールをまとめると役に立ちます。保つことができ、またドメインルールを簡単にテストできるようになります。ルールの無効化¶エンティティーを保存する時、必要であればルールを無効にできます。検証に二層のアプローチを使う点がユニークです。目はバリデーションです。バリデーションルールは、ステートレスな方法の操作を意図しています。それらは、形状、データ型、データの書式が正しいことを保証するために最もよく作用します。二層目は、アプリケーションルールです。ステートフルなプロパティーのチェックに最もよく作用します。メールアドレスがユニークであることを保証できます。オブジェクトを通して行われます。「カスタム」バリデータを使用します。$validator;}バリデーションは文字列や配列を渡されることを想定しています。メソッドのためにのみ起動されるので、エンティティーは保存されてしまうことになります。検証の第二層がこの状況に対処します。呼ばれるといつでもチェックされます。アプリケーション中で生成されたデータの変更に特化しています。両方に対して同じ検証の処理を走らせたいかもしれません。スクリプトを走らせる時に起こり得るでしょう。$rules;}保存が実行されると、追加された新しいアプリケーションのおかげで失敗します。使う時にも期待できます。