注解非常好,我们将它们用于代码生成,以便我们可以根据Doctrine EntityManger返回的模式属性定义表单元素行为。我希望注释能够将更多的实体定义放在一个地方,并使它们更容易管理,到目前为止这是事实。
这就是说,我发现注释有点不灵活,因为由注释分配的属性不能被子类中的其他注释覆盖。
在运行时很容易覆盖使用注释设置的属性,但不能用更多的注释来完成。 (可能是明显的。)
所以我在做我的控制器操作覆盖此刻。
例子:
$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());
正如我才刚刚开始需要应用自定义的验证规则,并预期这些措施随着时间的推移更加复杂,甚至有条件的,我想我会想移动我的表单生成器从控制器和模型中移出。原因是,当/如果我开始定义有条件的验证规则时,该逻辑位于它所属的模型中。这将清理Controller操作,因为所有表单程序集都变成了黑盒子方法。
例子:
$form = $myEntityModel->buildForm($myEntity);
// carry on with the form as normal
$form->setData($this->getRequest()->getQuery());
所以我不认为它很重要,你是否使用注释来定义您的默认输入的规则。无论您最初如何定义它们,您都将根据业务逻辑修改这些内容。
这听起来像你可能会受益于将表单程序集移动到您的模型类中,以实现将验证规则与实体完全分离的目标。我相信你的直觉是正确的,商业逻辑需要留在模型中,而不是在控制器或实体中。