php – Symfony2表单组件 – 违反MVC和SRP?

前端之家收集整理的这篇文章主要介绍了php – Symfony2表单组件 – 违反MVC和SRP?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我使用Symfony2越多,与它形成斗争越多,我得出的结论是,他们是一个巨大的可怕的野兽,甚至不应该真的存在.

我来了这篇文章here,我发现我同意作者的看法.即使文章是Symfony 1.x,我认为它仍然适用于Symfony2中的Form组件.它似乎像表单组件试图解决属于模板,控制器和模型的问题,在一个地方.这不会严重违反MVC和/或SRP(单一责任原则)吗?

这可能是一个不同的问题,但我觉得这是一种相关的 – 我也注意到,symfony的许多可用捆绑包试图解决视图外的视图问题,例如:

KnpMenuBundle – 在服务器端使用oo界面生成菜单(为什么不在它们所属的视图层中?)

IvoryCKEditorBundle – 将textarea转换为ckeditor是在视图文件中的一个jQuery行中完成的,为什么这个包存在?我甚至不想计算那里的行数.

那么似乎在Symfony核心的地方有这些侵权行为,还是我没有得到它?

表单处理的问题是它违反了MVC的定义.这是一个被称为“横切”的问题,过去已经被科学研究了.例如,论文 Domain Driven Web Development With WebJinn是关于这个话题的一个有趣的阅读.

例如,考虑形式与MVC不同层次的关系:

模型:

> Forms复制您的域模型(DM)的信息结构.如果您更改此结构(例如,通过向数据结构添加字段或通过向过程添加参数),还必须调整表单以输入该信息.
>他们需要DM的类型信息,将输入转换为所需的类型.
>他们需要知道DM中指定的约束来验证输入.
他们理想地直接从DM读取数据(例如通过读取/写入数据结构的字段,或通过使用提交的值作为参数调用DM中的过程).

控制器:

>表单接收提交的数据并发送给DM.
>他们根据是否成功验证来改变程序流程.

视图:

>表单渲染为HTML标签属性的复杂结构,这取决于所有上述内容(应该是字段,需要显示错误?如何排序字段?下拉列表中提供哪些选项等)

因此,不可能编写不接触所有这些层的表单抽象机制.相反,解决方案是根据MVC将表单库本身组织成不同的层次和满足SRP的子组件.如果您查看Symfony2表单组件,它的效果非常好. 原文链接:https://www.f2er.com/php/131673.html

猜你在找的PHP相关文章