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

Question

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

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

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

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

但我不知道我是否应该在项目中使用这种多模块结构而不是使用多项目。 我能想到的是：更复杂的配置，复杂的文件夹结构，我的网址更长（/ [模块] / [控制器] / [动作]），更重要的是，性能会很低（对于更多的加载而言） 。

但是，我认为它有一些有趣的东西（很多ITer都使用过它）。 是否有人可以给我优势，劣势和选择标准。

P / s：Zend2模块的问题一样！

Answer 1

如果要将单用途应用程序构建为不使用视图的API，则应该使用单个模块结构。 如果它是一个真正简单的API，例如存储/日志记录，微应用程序也会这样做。

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

我的习惯是使用多模块结构，因为我必须使用他们的API和公共可访问的内容部分（例如，docs）来构建CRM的应用程序。 为此目的，创建以下模块非常方便：

• 前端 - 适用于每个人都可以访问的控制器
• 后端 - 用于在管理员身份等身份验证和授权后可访问的控制器
• API - 用于API目的;）
• common - 我宁愿不愿意实现的部分，但是在一个项目中，我不得不把一些抽象的控制器放在这里，这些控制器将在其他模块中扩展。

通过这种方式，您可以为每个模块保留单独的服务配置，这样可以避免您在模块A的目的中切断正在使用的内容 ，而不是模块B上的内容 。 像身份验证部分 - 对后端很重要，但对于前端部分则无用 。 或者数据库配置 - 前端的奴隶，后端的主服务器等等。因此，对于大型项目，这也可能是性能方面的解决方案。

更新

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

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

Answer 2

好吧，例如我在我的应用程序中我分裂每个功能 - 例如我有模型链接 - 它被拆分为单独的模块，以具有良好的应用程序结构，其中每个功能是分离模块。 这就像在加载器中加载更少的类。 因为你只需要从每个模块中加载模型和路由来加载整个应用程序，然后在模块中加载librarys / controllers / helpers / services等其他东西。