Zend 框架 MVC 设计
我也在 zfforums 上问过这个问题，但也许我会在这里得到答复。
所以Zend Framework是一个通用的、灵活的、松耦合的、高质量的框架。 然而，我发现一些 MVC 部分不一致并且过于复杂。 希望你们中的一些人能够证明一些 zf 设计决策的合理性并回答一些问题：
一般问题/评论
为什么 zend mvc 不遵循与其他 zend 组件相同的命名约定？ 例如，mvc 使用小写、复数目录名，并且类名没有目录信息前缀，因此无法轻松自动加载。
我想要添加模块根目录的选项。 这样，我就不必通过添加控制器/模块目录来显式配置调度程序。 我能够放入模块并立即对其进行访问。
为什么视图助手和操作助手之间存在区别？ 目前，帮助程序并未设计为在整个代码中共享，并且加载和访问帮助程序的方法不一致。 其他框架允许您在代码中的任何位置共享相同的帮助程序。 我不认为有必要专门化和违反 DRY。
Zend View 问题
为什么视图使用“$this”来访问资源？ 我认为没有必要额外打字。 其他一些框架 extract() 视图变量数组并允许从视图内加载全局函数或自动加载静态助手： myHelper::someMethod();
为什么视图助手每个类只允许一个函数？ 这会导致大量的课程和相关的维护。 正如已经提到的，我更喜欢具有任意数量方法的静态类。
I've asked this question on the zfforums as well, but I maybe I'll get a response here.
So the Zend Framework is a general purpose, flexible, loosly coupled, high quality framework. However, I find some of the MVC parts inconsistent and overly complex. Hopefully some of you can justify some of the zf design decisions and answer some questions:
General Questions/Comments
Why doesn't zend mvc follow the same naming conventions as other zend components? For example, mvc uses lower case, plural directory names and class names aren't prefixed with directory info so they can't be easily autoloaded.
I'd like the option to add a module root directory. That way, I wouldn't have to explicitly configure the dispatcher by adding controller/module directories. I'd be able to drop in a module and have it accessible immediately.
Why is there a distinction between view and action helpers? Currently, the helpers aren't designed to be shared throughout the code and there are inconsistent methods of loading and accessing the helpers. Other frameworks allow you to share the same helpers anywhere in your code. I don't see the need to specialize and violate DRY.
Zend View Questions
Why do views use "$this" to access resources? I don't see the need for the extra typing. Some other frameworks extract() an array of view variables and allow loading global functions or autoloading static helpers from within the view: myHelper::someMethod();
Why do view helpers only allow one function per class? That results in a lot of classes and associated maintenance. I'd prefer static classes with any number of methods as already mentioned.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我在一个巨大的内联网站点中使用 Zend 框架，因为它还处于早期阶段，我认为是 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< /code> 模块/admin控制器）。例如，您可以将模块目录设置为
applicatoin/modules，并将 FrontController 配置为查看此目录中的模块。 使用 addModuleDictory 每当您创建新目录并将视图/控制器放在那里时，调度程序都会自动发现它们。 这里是一个示例。据我所知，它们有着明显不同的目的。 ViewHelpers 用于生成标记并直接在视图中渲染其他操作，抽象菜单创建、侧边栏等。OTOH ActionHelpers 与调度进程交互，例如，允许您重定向到另一个操作。
Views
一开始我也觉得有点别扭，但后来就习惯了。 我认为主要原因是不污染名称空间，但我的看法可能是错误的。 顺便说一下，我不太喜欢使用
extract()，但这只是我个人的偏好。不允许每个文件有多个控制器的主要原因是：自动加载。 当您使用
$this->someViewHelper()时，底层引擎会在插件路径中查找名为*_SomeViewHelper_Helper的类。 另一个原因是静态类很难进行单元测试。 甚至有人建议将 FrontController 重写为实例类，而不是 Singleton。您在第二段中所说的过于复杂的部分是正确的，开发人员和社区都知道这一点。 它必须以这种方式满足所有要求和变化。
最后，我认为采埃孚是一个非常强大的框架，让我们可以自由地做我们想做的事情。
我希望我能帮助您解答疑问。
I´m using the Zend Framework in a huge intranet site, since it´s early stages, 0.3 or 0.4 I think, and I followed the most of decisions regarding your questions. I´ll try to explain them a bit:
In most cases you don´t need to use modules. You can drop all your controllers in your
application/defaultdirectory, name themIndexControllerorHelpControllerand you´re done, just accesshttp://www.domain.com/orhttp://www.domain.com/help.If your project starts go grow you can add modules as you wish, prefixing them with the name of the module (directory name)
Admin_IndexControllerorForum_PostController, acessing them byhttp://www.domain.com/admin(you´re inadminmodule,indexcontroller; not indefaultmodule/admincontroller).You can set your modules directory at
applicatoin/modules, for example, and configure the FrontController to look at this directory for modules. Using addModuleDictory Whenever you create a new directory and put your view/controllers there, they´re auto-discovered by the dispatcher. Here is an example.As I see they serve clearly distinct purposes. ViewHelpers are used to generate markup and render other actions directly in the view, abstracting menu creation, sidebar, etc. OTOH ActionHelpers interact with the dispatch process, allowing you to redirect to another action, as an example.
Views
In the beggining I too felt it a little awkward, but I got used to. I think the main reason is not to pollute the namespace, but I can be wrong with this. By the way I´m not very fond of the use of
extract(), but it´s just my personal preference.For the main reason that it´s not allowed to have more than one controller per file: autoloading. When you use
$this->someViewHelper()the underlying engine looks for a class named*_SomeViewHelper_Helperin your plugin paths. Another reason is that static classes are very hard to unit test against. There´s even a proposal to rewrite the FrontController as an instance class, not a Singleton.You´re right about the overly complex part that you say in your second paragraph and the developers and community knows about it. It just has to be this way to accomodate all requiriments and variations.
In the end I think that ZF is a very robust framework, giving us the freedom to do what we want.
I hope I could help you clearing your questions.
我不知道这些问题的所有答案，但它们都是有趣的问题，所以我会尝试一下，希望有人可以填补空白。
常规
不在默认模块中的类以模块名称为前缀，例如Admin_IndexController，并且将驻留在/admin/controllers 中。 我认为分离和命名不一致（与库类相比）的原因是，将它们放在嵌套文件夹结构中几乎没有什么好处。 控制器是您实现的一部分，因此我个人认为这是有意义的。 然而，遍历文件夹确实有点烦人。
您可以修改调度程序，或者编写一个插件来扫描目录并添加它们。
这里肯定有重叠 - URL 帮助器就是一个很好的例子。 一般来说，视图助手会生成标记，所以我认为有足够大的区别。
查看
我不知道确切的原因，但我猜它可以让其他助手和视图功能更轻松地协同工作。 例如，如果您使用 doctype 帮助器来设置 doctype，则表单元素帮助器可以根据需要生成 XHTML 或 HTML。
这肯定会导致很多课程，但我不确定维护。 我没有遇到任何问题。 我可以看到静态类中的使用，但请记住 Zend_View 不会阻止您使用它们。 如果您的包含路径中有静态类（并使用 Zend_Loader 或类似的），您可以使用它们来代替 View Helpers 或作为 View Helpers 的补充。
I don't know all the answers to these but they're interesting questions so I'll have a stab and hopefully someone can fill in the blanks.
General
Classes not in the default module are prefixed with the module name, e.g. Admin_IndexController and would reside in /admin/controllers. I think the reason for the separation, and inconsistent naming (vs. library classes) is that there would be little benefit having them in a nested folder structure. Controllers are part of your implementation so I think it makes sense, personally. Traversing the folders does get a little tiresome, however.
You could modify the dispatcher, or write a plugin to scan for directories and add them.
There is definitely overlap here - the URL helpers are a good example of this. Generally a view helper generates markup so I think there's a big enough distinction.
View
I don't know the exact reason but I'd guess it allows other helpers and view functionality to work together more easily. For example, if you've used the doctype helper to set the doctype, the form element helpers can generate XHTML or HTML as appropriate.
It definitely results in a lot of classes, but I'm not sure about maintenance. I've not run in to any problems. I can see the use in static classes, but remember that Zend_View won't stop you using them. If you have your static classes in your include path (and use Zend_Loader or similar), you can use them instead of or in addition to View Helpers.