1

ZF2 Rest サービスで Doctrine 2 エンティティを検証する最善の方法に苦労しています。最初に、Zend\InputFilter\InputFilter を拡張して検証を実装し、拡張されたクラス内のフィルターにバリデーターを追加しました。私の検証はエンティティクラスから完全に分離されているため、これが最善のアプローチであるかどうかはわかりません。

マシューの記事http://mwop.net/blog/2012-07-02-zf2-beta5-forms.htmlで説明されているように、注釈を使用して検証を実装することを考えましたが、エンティティをインスタンス化するとき、コンストラクターで引数を使用することがよくあります。私の意見では、これはこのアプローチではうまく機能しません。

さらに、エンティティのステータスに応じて、エンティティの検証ルールが異なることがよくあります。たとえば、BlogPost エンティティがあり、それが「下書き」ステータスにある場合、フィールドのサブセットのみが必要になる場合があります。ステータスが「公開済み」の場合は、すべてのフィールドを必須にすることができます。

ここで取るべき最善のアプローチに関するアイデアはありますか? これは REST 実装であるため、Zend\Form が提供するビジュアルは必要ありません。\Zend\InputFilter\InputFilter を拡張するアプローチを続けるべきですか? または、注釈の方向に進む必要がありますか?

4

1 に答える 1

0

アノテーションは素晴らしいので、Doctrine EntityManger によって返されるスキーマ プロパティに基づいてフォーム要素の動作を定義できるように、コード生成でアノテーションを使用しています。私は、注釈によってエンティティ定義を 1 か所にまとめて管理しやすくすることを期待していましたが、これまでのところその通りです。

そうは言っても、注釈によって割り当てられた属性をサブクラスの他の注釈でオーバーライドできないという点で、注釈は少し柔軟性に欠けていることがわかりました。

実行時にアノテーションで設定された属性をオーバーライドするのは簡単ですが、それ以上のアノテーションではできません。（明白なことを述べているかもしれません。）

そのため、現在、コントローラーのアクションでオーバーライドを行っています。

例：

    $builder = new AnnotationBuilder();
    $form = $builder->createForm($myEntity);

    // customize the the InputFilter for myElement
    $form->getInputFilter()->get('myElement')->setAllowEmpty(FALSE);
    $form->getInputFilter()->get('myElement')->setRequired(TRUE);
    $form->getInputFilter()->get('myElement')->getValidatorChain()->addValidator(new \Zend\Validator\NotEmpty('all'));

    // carry on with the form as normal
    $form->setData($this->getRequest()->getQuery());

カスタム検証ルールを適用する必要が生じ始めたばかりであり、これらは時間の経過とともに複雑になり、おそらく条件付きでさえあると予想されるため、フォームビルダーをコントローラーからモデルに移動したいと思うでしょう。その理由は、条件付きの検証ルールの定義を開始するとき/場合、そのロジックはそれが属するモデルにあります。これにより、すべてのフォーム アセンブリがブラック ボックス メソッドに変換されるため、コントローラー アクションもクリーンアップされます。

例：

    $form = $myEntityModel->buildForm($myEntity);

    // carry on with the form as normal
    $form->setData($this->getRequest()->getQuery());

したがって、注釈を使用してデフォルトの入力規則を定義するかどうかは問題ではないと思います。最初にそれらをどのように定義したかに関係なく、ビジネス ロジックに従ってそれらを変更します。

検証ルールをエンティティから完全に分離するという目標を達成するために、フォーム アセンブリをモデル クラスに移動することでメリットが得られるように思えます。ビジネス ロジックは、コントローラーやエンティティではなく、モデルにとどまる必要があるというあなたの本能は正しいと思います。

于 2012-11-10T01:19:24.703 に答える