何时在 Zend Framework 中使用模块？
设置新的 ZF 项目时，我通常具有以下目录结构：
- application
- 模块
- 默认
- 控制器
- 表格
- 查看
- 型号
- 管理员
- 控制器
- 表格
- 查看
- 型号
- 默认
- 语言
- 已共享
- 型号
- 模块
- library
- public
我只在布局不同或使用不同的数据库时使用模块，或者当然当它是一个非常特殊的情况（如管理后端或论坛/板）时。然后我有用于应用程序不同部分的控制器。例如JobController、ProductController等。
我的一位同事向我展示了他的基地布局。几乎是一样的，但是他使用了很多模块。像 Job-Module、Product-Module 一样，每个模块大多有 2 个控制器：一个 IndexController 和一个 AdminController。
他的设置有效并且没有错误，但我从未见过这样的方法，它似乎不需要复杂。
结束语：
- 你什么时候会使用模块以及什么时候你会坚持使用 控制器？
- 你决定模块或不模块的规则是什么？
- 我同事的设置有何优缺点按照你的观点 的观点？
- 在您看来，我的设置的缺点和优点是什么？
TIA
Rufinus
编辑 ：参见http://mwop.net/blog/2012-04-30 -why-modules.html 了解 ZF2.0 中重新设计的模块的信息
When setting up new ZF Projects i normaly have this directory structure:
- application
- modules
- default
- controller
- forms
- view
- models
- admin
- controller
- forms
- view
- models
- default
- language
- shared
- models
- modules
- library
- public
I use only modules when e.g the layout is diffrent, or a diffrent database is used, or of course when its a very special case like a admin-backend or a forum/board. Then i have Controller for the different parts of the application. e.g JobController, ProductController and so on.
A colleague of mine showed me his base layout. its nearly the same, but he uses a lot of modules. like Job-Module, Product-Module each of this modules mostly have 2 Controllers an IndexController and an AdminController.
His setup works and isnt wrong, but i never saw such an approach, its seems unneeded complicated.
So to come to an end:
- When would you use Modules and when you would stick to
Controllers? - Whats your rule to decide Module or not Module ?
- What are the cons AND pros of my colleague's setup in your point
of view? - What are the cons AND pros of my setup in your point of view?
TIA
Rufinus
EDIT: see http://mwop.net/blog/2012-04-30-why-modules.html for info on the redesigned modules in ZF2.0
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
更好的可重用性。假设您的同事将模块内的代码独立于其他模块，那么他有效地创建了一个独立的问题域。与您的方法不同，他可以更轻松地将整个模块复制到其他应用程序。
Better Reusability. Assuming your colleague kept the code inside the modules indepedent from other modules, he effectively created a self-contained problem domain. Unlike with your approach, he can more easily copy the entire module over to other applications then.
和你一样。对于我网站的主要部分，如前端、管理部分、会员部分等......
它是主站点的一部分还是它自己的小世界，只与前端相关？
尤其是在设计方面。如何管理几个使用相同布局的模块？
我的天啊，维护。所有这些文件夹根本没有任何意义。为什么您的“关于”页面和联系页面采用两种不同的文件结构？另外，如果他使用简单页面的模块，他会将管理员和成员放在哪里？
确实与上面相反。易于理解且结构连贯。
值得以 zend 团队希望我们使用它的方式添加它 link
另一件需要考虑的事情是您的网址是什么样的。
myapp.com/contact
myapp.com/about
myapp.com/members/profile
myapp.com/members/profile/edit
myapp.com/members/mail
这是帮助组织模块或控制器中内容的一种简单方法。
Same as you. For major sections of my website like the front-end, admin section, members section, etc...
Is it part of the main site or its own little world just related to the front end?
Especially in regards to design. How do you manage a couple of modules some using the same layout?
My God the maintenance. All these folders for nothing at all. Why have your about page and contact page in two different file structures? Also where does he put admin and members if he uses modules for simple pages?
Really the opposite of the above. Easy to understand and coherant structure.
Its worth it to add its the way the zend team intended us to use it link
Another thing to think about is what will your urls look like.
myapp.com/contact
myapp.com/about
myapp.com/members/profile
myapp.com/members/profile/edit
myapp.com/members/mail
This is one easy way to help organise what will go in modules or controllers.
这种描述给我带来了危险。如果这是一个非常大的项目，需要依赖于高可重用性，并且如果他以一种可以独立于系统中其他模块工作的方式编码这些模块，并且如果需要隔离每个模块的管理区域，那么这可以被认为是一个合理的做法。
但我认为作业和产品之间可能存在依赖关系，在这种情况下，这种模块方法听起来像是过度设计。特别是如果似乎强制执行任意“规则”（例如每个模块一个业务对象）。
此外，大多数 MVC 框架会假设，如果您有 Job 和 Product 模型，那么您就有 Job 和 Product 控制器（而不是每个实体的 IndexController）。模块的目的是分离站点的逻辑和表示区域，而不是划分业务逻辑。
虽然就正确的 MVC 而言，它可能既不在这里也不在那里，但对我来说，创建一个不能完全独立于其他模块运行的模块是没有意义的。
That description kind of raises a red flag to me. IF this was a really big project that needed to rely on high resusability and IF he coded such modules in a way that they could work independently of other modules in the the system and IF there was a need to isolate the admin area for each module, then this could be considered a reasonable approach.
But I would assume there's likely a dependency between Job and Product, in which case, this module approach sounds like over-engineering. Especially if there seems to be an arbitrary 'rule' being enforced (like one business object per module).
Also, most MVC frameworks would assume that if you have Job and Product models, you have Job and Product controllers (not an IndexController for each entity). The purpose of modules is to segregate logical and presentational areas of your site, not divide up business logic.
While it's probably neither here nor there as far as proper MVC is concerned, it doesn't make sense to me to create a module that cannot operate fully independent from other modules.
问）什么时候会使用模块，什么时候会坚持使用控制器？
A）对我来说，一切都与应用程序的大小有关。当您有超过 10 个控制器时，您可能需要考虑将其中一些重构为单独的模块。如果您计划构建一个非常大的应用程序，那么在开始之前将其分解为模块可能是值得的。
Q) 你决定 Module 或 not Module 的规则是什么？
A) 就像我说的有超过 10 个控制器。
问）您认为我同事的设置有何优缺点？
A) 如果这是一个小项目，他就会过度设计，这将使其他开发人员更难参与，并且会花费他比最初开发所需的时间更长的时间。他还冒着让自己困惑的风险。
问）您认为我的设置有哪些缺点和优点？
A）我上面的回答几乎涵盖了它，如果它是一个较小的项目，从长远来看，你的方式会更快并且更少混乱。我更喜欢这种方法，如果范围扩大，只需重新考虑即可。
Q) When would you use Modules and when you would stick to Controllers?
A) For me its all about the size of the application. When you have more than say 10 controllers you might want to think about refactoring some of them into a separate module. If you are planning on building a REALLY BIG application it may be worth spitting it up into modules before you start.
Q) Whats your rule to decide Module or not Module ?
A) Like I said having more than 10 controllers.
Q) What are the cons AND pros of my colleague's setup in your point of view?
A) If it is a small project he is over engineering it which will make it harder for other developers to jump into and will take him longer than needed to develop in the first place. He also runs the risk of confusing himself.
Q) What are the cons AND pros of my setup in your point of view?
A) My answer above pretty much covers it, if it's a smaller project your way will be quicker and less confusing in the long run. I prefer this approach and just re-factor if the scope is increased.