注释很棒,我们将它们与代码生成一起使用,以便我们可以根据 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());
由于我才刚刚开始需要应用自定义验证规则,并且预计这些规则会随着时间的推移变得更加复杂,甚至可能是有条件的,因此我希望我希望将表单构建器从控制器中移到模型中。原因是,当/如果我开始定义有条件的验证规则时,该逻辑在它所属的模型中。这也将清理控制器操作,因为所有表单组件都变成了黑盒方法。
例子:
$form = $myEntityModel->buildForm($myEntity);
// carry on with the form as normal
$form->setData($this->getRequest()->getQuery());
所以我认为你是否使用注释来定义你的默认输入规则并不重要。无论您最初如何定义它们,您都将根据业务逻辑修改它们。
在我看来,您可能会受益于将表单组装移动到模型类中以实现将验证规则与实体完全分离的目标。我相信您的直觉是正确的,业务逻辑需要保留在模型中,而不是控制器或实体中。