我们什么时候应该在 php Phalcon 中使用多模块结构（而不是简单结构）答案

【问题标题】：When should we use multi-module structure (instead simple structure) in php Phalcon我们什么时候应该在 php Phalcon 中使用多模块结构（而不是简单结构）
【发布时间】：2016-02-23 05:02:54
【问题描述】：

什么时候应该在php Phalcon中使用多模块结构（而不是简单结构）？

我找到了一些多模块的骨架，比如：

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

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

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

但是，我认为它有一些有趣的地方（很多 ITer 都使用过它）。有没有人可以告诉我选择的优缺点和标准。

P/s：Zend2 Module 也有同样的问题！

【问题讨论】：

标签： php phalcon multi-module

【解决方案1】：

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

如果您愿意构建更复杂的解决方案，多模块应用程序结构将非常有用。例如具有公共内容但具有管理面板的公共应用程序。这个可以方便地编写多模块以将管理控制器/视图与那些公共的分开。

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

前端 - 每个人都可以访问的控制器
后端 - 用于经过身份验证和授权后可访问的控制器，例如管理事务
API - 用于 API 目的 ;)
common - 我宁愿不实现的部分，但在一个项目中，我不得不在这里放置一些将在其他模块中扩展的抽象控制器。

这样您可以为每个模块保留单独的服务配置，这样您就可以避免切断您在模块 A 上使用的东西，而不是在模块 B。像身份验证部分 - 对于 backend 很重要，但对于 frontend 部分没用。或者数据库配置 - 前端的从属服务器，后端的主服务器等。所以这也可能是大型项目的性能方面的解决方案。

更新

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

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

【讨论】：

非常感谢您的回答！我要构建一个多部分的复杂项目（和你说的一样）：管理端（后端），客户端（前端），api（对于一些常见的服务使用 RESTFul），......我'我想知道在“多模块项目”和“多项目”之间进行选择。如果我使用“多项目”，我会失去什么？这些东西可以在模块之间共享吗？还有别的吗？
谢谢，您的意见对我很有帮助，我会在开始我的项目之前仔细考虑......

【解决方案2】：

例如，我在我的应用程序中拆分每个功能 - 例如我有模型链接 - 它被拆分为单独的模块以具有良好的应用程序结构，其中每个功能都是单独的模块。这就像在加载器中加载的类更少。因为您只需要每个模块中的模型和路由来为整个应用程序加载，并且您在模块中加载库/控制器/帮助程序/服务等其他内容。

【讨论】：