我来了这篇文章here,我发现我同意作者的看法.即使文章是Symfony 1.x,我认为它仍然适用于Symfony2中的Form组件.它似乎像表单组件试图解决属于模板,控制器和模型的问题,在一个地方.这不会严重违反MVC和/或SRP(单一责任原则)吗？
这可能是一个不同的问题,但我觉得这是一种相关的 – 我也注意到,symfony的许多可用捆绑包试图解决视图外的视图问题,例如：
KnpMenuBundle – 在服务器端使用oo界面生成菜单(为什么不在它们所属的视图层中？)
IvoryCKEditorBundle – 将textarea转换为ckeditor是在视图文件中的一个jQuery行中完成的,为什么这个包存在？我甚至不想计算那里的行数.
那么似乎在Symfony核心的地方有这些侵权行为,还是我没有得到它？
例如,考虑形式与MVC不同层次的关系：
模型：
> Forms复制您的域模型(DM)的信息结构.如果您更改此结构(例如,通过向数据结构添加字段或通过向过程添加参数),还必须调整表单以输入该信息.
>他们需要DM的类型信息,将输入转换为所需的类型.
>他们需要知道DM中指定的约束来验证输入.
他们理想地直接从DM读取数据(例如通过读取/写入数据结构的字段,或通过使用提交的值作为参数调用DM中的过程).
控制器：
>表单接收提交的数据并发送给DM.
>他们根据是否成功验证来改变程序流程.
视图：
>表单渲染为HTML标签和属性的复杂结构,这取决于所有上述内容(应该是字段,需要显示错误？如何排序字段？下拉列表中提供哪些选项等)
因此,不可能编写不接触所有这些层的表单抽象机制.相反,解决方案是根据MVC将表单库本身组织成不同的层次和满足SRP的子组件.如果您查看Symfony2表单组件,它的效果非常好.
