Question

我正在为一个（哦不，另一个）PHP框架编写一些零碎的东西作为学习经验，并希望将来用于较小的项目。

我已经做了很多阅读，即现有框架的参考文档。我看到了很多文字 Module ，从我的阅读和以前的经验来看，模块是一个应用于划分相关代码的概念（视图，控制器，模型等）

我很好奇，在这种情况下，SO如何看待模块？（上下文是MVC Web应用程序体系结构，或类似的应用程序开发模式）

我正在努力确定如何最好地应用它，因为（我相信）它符合我目前的困境。对于音乐网站，模块将被视为Artist，Producer等，而控制器将为Profile，Media等。这当然会留下行动，例如View或Edit。

这一切似乎都很好，因为现在我可以像这样做路由：

'Artist/Profile/View/{ALIAS}'
    +- Module : Artist
    +- Controller : Profile
    +- Action : View

//this may be accessed via music.com/artist/{alias}
//defaulting the Controller and Action

..但我正在试图找出模块概念如何适合这里，具体来说，我将如何组织或修改我的控制器以适应。

这是我正在考虑的那种文件系统布局;

+- Root
    +- 'index.php'
    +- 'api.php'
    +- Modules
    |   +- Public
    |   |   +- Controllers
    |   |   +- Views
    |   |
    |   +- User
    |   |   +- Controllers
    |   |   +- Views
    |   |
    |   +- Artist
    |   |   +- Controllers
    |   |   +- Views
    |   |
    |   +- Producer
    |   |   +- Controllers
    |   |   +- Views
    |   |
    |   +- Venue
    |   |   +- Controllers
    |   |   +- Views
    |   |
    |   +- Administrator
    |       +- Controllers
    |       +- Views
    |
    +- Models
    +- Config
    +- ...

Answer 1

模块（在CakePHP中称为插件）在大多数框架中都是非常迷你的应用程序。它们内部有自己的MVC结构，通常是自包含的，可能只依赖主要的应用程序模型来保持代码可重用。

我们在工作的地方使用Zend，模块的例子是

管理模块，供网站管理员对系统进行更改。
网站常规前端的网络模块
具有其他管理工具以在网站上执行活动的已登录用户的用户模块

基本上所有这些都属于同一个站点/系统，但大多数都是非重叠的。

Answer 2

在最简单的情况下，模块将是您app中的文件夹（最好是在预先确定的位置，如/modules）。然后，您将在每个模块中拥有一个完整的MVC堆栈，共享库和框架本身位于顶层。

模块与控制器

2 个答案: