我也在zfforums上问过这个问题，但我可能会在这里得到回复。
因此，Zend Framework是一个通用，灵活，松散耦合，高质量的框架。但是，我发现一些MVC部分不一致且过于复杂。希望你们中的一些人能够证明某些zf设计决策并回答一些问题：
一般问题/评论
为什么zend mvc遵循与其他zend组件相同的命名约定？例如，mvc使用小写，多个目录名称和类名称不以目录信息为前缀，因此无法轻松自动加载。
我想要添加模块根目录的选项。这样，我就不必通过添加控制器/模块目录来显式配置调度程序。我可以放入一个模块并立即访问它。
为什么视图和动作助手之间有区别？目前，帮助程序并非设计为在整个代码中共享，并且存在加载和访问帮助程序的不一致方法。其他框架允许您在代码中的任何位置共享相同的帮助程序。我认为不需要专门化和违反DRY。
Zend查看问题
为什么视图使用“$ this”来访问资源？我没有看到额外打字的需要。其他一些框架提取（）一个视图变量数组，允许从视图中加载全局函数或自动加载静态助手：myHelper :: someMethod（）;
为什么视图帮助程序每个类只允许一个函数？这导致了很多课程和相关的维护。我更喜欢使用已经提到的任何方法的静态类。
答案 0 :(得分：5)
我在一个庞大的内部网站点使用Zend Framework，因为它是早期阶段，我认为是0.3或0.4，而且我遵循了大部分关于你的问题的决定。我会尝试解释一下：
在大多数情况下，您不需要使用模块。您可以将所有控制器放在application/default目录中，将其命名为IndexController或HelpController并完成操作，只需访问http://www.domain.com/或http://www.domain.com/help即可。
如果您的项目开始增长，您可以根据需要添加模块，在其前面加上模块名称（目录名称）Admin_IndexController或Forum_PostController，按http://www.domain.com/admin访问它们（您在admin模块，index控制器中;不在default模块/ admin控制器中。
例如，您可以在applicatoin/modules设置模块目录，并配置FrontController以查看此目录中的模块。使用addModuleDictory无论何时创建新目录并将视图/控制器放在那里，调度程序都会自动发现它们。 Here就是一个例子。
我认为它们的用途明显不同。 ViewHelpers用于生成标记并直接在视图中呈现其他操作，抽象菜单创建，侧边栏等.OTOH ActionHelpers与调度过程交互，允许您重定向到另一个操作，作为示例。
浏览
在开始的时候，我觉得它有点尴尬，但我已经习惯了。我认为主要原因不是污染命名空间，但我可能错了。顺便说一句，我不是很喜欢使用extract()，但这只是我个人的偏好。
主要原因是每个文件不允许有多个控制器：自动加载。当您使用$this->someViewHelper()时，底层引擎会在插件路径中查找名为*_SomeViewHelper_Helper的类。另一个原因是静态类很难进行单元测试。甚至有人建议将FrontController重写为实例类，而不是Singleton。
你对你在第二段中所说的过于复杂的部分以及开发人员和社区对此的了解是正确的。它必须以这种方式来满足所有需求和变化。
最后我认为ZF是一个非常强大的框架，让我们可以自由地做我们想要的事情。
我希望我能帮你解决问题。
答案 1 :(得分：2)
我不知道这些的所有答案，但它们是有趣的问题所以我会有一个刺，希望有人可以填补空白。
一般
不在默认模块中的类以模块名称为前缀，例如Admin_IndexController并将驻留在/ admin / controllers中。我认为分离的原因和不一致的命名（与库类相比）是在嵌套文件夹结构中使用它们几乎没有什么好处。控制器是您实现的一部分，所以我认为这是有道理的。然而，遍历文件夹确实有点令人厌烦。
您可以修改调度程序，或编写插件来扫描目录并添加它们。
这里肯定有重叠 - 网址助手就是一个很好的例子。通常，视图助手会生成标记，因此我认为这有很大的区别。
查看
我不知道具体原因，但我猜它可以让其他帮助者和查看功能更容易地协同工作。例如，如果您已使用doctype帮助程序设置doctype，则表单元素帮助程序可以根据需要生成XHTML或HTML。
肯定会导致很多课程，但我不确定维护。我没有遇到任何问题。我可以在静态类中看到它的用法，但请记住，Zend_View不会阻止你使用它们。如果你的包含路径中有静态类（并使用Zend_Loader或类似的），你可以使用它们代替View Helpers或者除了View Helpers之外使用它们。