php - 我们什么时候应该在 php Phalcon 中使用多模块结构(而不​​是简单结构)

Question

我们什么时候应该在 php Phalcon 中使用多模块结构(而不​​是简单结构)？

我已经找到了一些多模块骨架，比如:

https://github.com/ovr/phalcon-module-skeleton ,

https://github.com/phalcon/mvc/tree/master/multiple .

但我不知道我应该在项目中使用这种多模块结构而不是使用多项目。 我能想到的是:更复杂的配置，复杂的文件夹结构，我的网址更长(/[module]/[controller]/[action])，重要的是，性能会很低(加载更多的东西) .

但是，我认为它有一些有趣的地方(很多 ITer 用过它)。有没有人可以给我优缺点和选择标准。

P/s: Zend2 Module 也有同样的问题!

Answer 1

如果您要将单一用途应用程序构建为不使用 View 的 API，则您应该使用单一模块结构。如果它将是一个非常简单的 API，例如存储/日志记录，微应用程序也可以。

如果您愿意构建更复杂的解决方案，多模块应用程序结构非常有用。例如，具有公共(public)内容但带有管理面板的公共(public)应用程序。这一个在多模块中编写以将管理 Controller / View 与那些公共(public) Controller / View 分开会很方便。

我的习惯是使用多模块结构，因为大多数情况下我必须构建 CRM 应用程序及其 API 和公共(public)可访问的内容部分(例如文档)。为此目的，创建这样的模块很方便:

• 前端 - 供所有人访问的 Controller
• backend - 用于在身份验证和授权后可访问的 Controller ，如管理事物
• API - 用于 API 目的；)
• common - 我宁愿不实现的部分，但在一个项目中，我被迫将一些抽象 Controller 放在这里，这些 Controller 将在其他模块中扩展。

通过这种方式，您可以为每个模块保留单独的服务配置，从而避免切断您在模块 A 而不是在模块 B。像身份验证部分 - 对后端很重要，但对前端部分没用。或数据库配置 - 前端的奴隶，后端的主人等。所以这也可能是大型项目的性能明智的解决方案。

更新

有时“多项目”是一个选项，包括“多模块”项目；)这在很大程度上取决于您要实现的目标。例如。如果您将 API 分开，那么在多个实例上扩展它可能会更容易，但首先您需要花费精力来配置单独的项目。

如果系统应该是单服务器实例或者每个实例都应该绝对独立于其他实例，那么单个多模块项目就足够了——比方说一个标准的 CMS、博客平台，甚至是简单的浏览器游戏或移动主页应用程序包括它的 API。但是，如果您要构建一整套应用程序，例如用于提供内容的内部 API、用于管理内容的 CRM 以及用于提供内容的几个网页，那么将这些作为单独的项目保留以后会更易于管理。