问Zend框架MVC设计

EN

我在一个巨大的内联网站点中使用，因为它的早期阶段是0.3或0.4，我认为，我遵循了大多数关于您的问题的决定。我试着解释一下：

1. 在大多数情况下，您不需要使用模块。您可以将所有控制器放在您的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控制器中)访问它们。
2. 例如，您可以在applicatoin/modules上设置模块目录，并将FrontController配置为查看模块的此目录。每当您创建一个新目录并将视图/控制器放置在其中时，就会使用addModuleDictory，调度员会自动发现它们。这里就是一个例子。
3. 据我所见，它们的用途显然是不同的。ViewHelpers用于在视图中直接生成标记和呈现其他操作，抽象菜单创建、侧边栏等。OTOH ActionHelpers与调度过程交互，例如允许您重定向到另一个操作。

视图

1. 在乞讨的过程中，我也觉得有点尴尬，但我习惯了。我认为主要原因不是为了污染名称空间，但这可能是错误的。顺便说一句，我不太喜欢使用extract()，但这只是我个人的喜好。
2. 主要原因是每个文件不允许有一个以上的控制器:自动加载。使用$this->someViewHelper()时，底层引擎将在插件路径中查找名为*_SomeViewHelper_Helper的类。另一个原因是静态类很难进行单元测试。甚至有人提议将FrontController重写为实例类，而不是Singleton类。

关于你在第二段中说的过于复杂的部分，你是对的，开发人员和社区都知道这一点。它只需要这样来容纳所有的要求和变化。

最后，我认为ZF是一个非常强大的框架，给我们做我们想做的事情的自由。

我希望我能帮你解决问题。

我不知道这些问题的全部答案，但它们是有趣的问题，所以我会尝试，希望有人能填补空白。

一般信息

1. 非默认模块中的类以模块名称(例如Admin_IndexController )作为前缀，并驻留在/admin/控制器中。我认为分离和不一致命名(相对于库类)的原因是，在嵌套的文件夹结构中使用它们几乎没有什么好处。控制器是您实现的一部分，所以我个人认为这是有意义的。然而，遍历这些文件夹确实有点令人厌烦。
2. 您可以修改dispatcher，或者编写插件来扫描目录并添加它们。
3. 这里肯定有重叠-- URL助手就是一个很好的例子。通常，视图助手会生成标记，所以我认为有足够大的区别。

视图

1. 我不知道确切的原因，但我想它可以让其他助手和查看功能更容易地协同工作。例如，如果您已经使用doctype助手来设置doctype，表单元素帮助程序可以酌情生成XHTML或HTML。
2. 它肯定会导致很多类，但我不确定如何维护。我没有遇到任何问题。我可以看到静态类中的用法，但请记住，Zend_View不会阻止您使用它们。如果包含路径中有静态类(并使用Zend_Loader或类似的类)，则可以使用它们代替视图助手，也可以添加到视图帮助器中。