我们什么时候应该在php Phalcon中使用多模块结构（而不是简单的结构）？
我找到了一些多模块骨架，例如：
https://github.com/ovr/phalcon-module-skeleton，
https://github.com/phalcon/mvc/tree/master/multiple。
但我不知道我是否应该在项目中使用这种多模块结构而不是使用多项目。 我能想到的是：更复杂的配置，复杂的文件夹结构，我的网址更长（/ [模块] / [控制器] / [动作]），更重要的是，性能会很低（对于更多的加载而言）
但是，我认为它有一些有趣的东西（很多ITer都使用过它）。是否有人可以给我优势，劣势和选择标准。
P / s：与Zend2模块一样的问题！
答案 0 :(得分：4)
如果要将单个用途的应用程序构建为不使用Views的API，则应该使用单个模块结构。如果它是一个真正简单的API，例如存储/日志记录，那么微型应用程序也会这样做。
如果您愿意构建更复杂的解决方案，则多模块应用程序结构非常有用。例如，具有公共内容的公共应用程序，但具有管理面板。这个在多模块中编写以将管理控制器/视图与那些公共控制器/视图分开是很方便的。
我的习惯是使用多模块结构，因为我必须构建具有API和公共可访问内容部分（例如docs）的CRM应用程序。为此目的，创建以下模块非常方便：
通过这种方式，您可以为每个模块保留单独的服务配置，这样可以避免在模块 A 的情况下切断您正在使用的内容，而不是模块 B 。与身份验证部分一样 - 对于后端非常重要，但对于前端部分则无用。或者数据库配置 - 前端的奴隶，后端的主服务器等等。因此，这对于大型项目来说也可能是性能方面的解决方案。
有时＆＃34;多项目＆＃34;是一个选项，包括＆＃34;多模块＆＃34;项目;）这很大程度上取决于你想要实现的目标。例如。如果你将API分开，可能更容易在多个实例上进行扩展，但首先需要一个efford来配置单独的项目。
如果系统应该是单服务器实例，或者每个实体应该完全独立于其他实例，单个多模块项目就足够了 - 让我们说一个标准的CMS，博客平台，甚至简单的浏览器游戏或移动主页应用程序包括它的API。但是，如果您正在建立一个完整的应用程序，如内部API以提供内容，管理它以及几个网页来提供服务，将这些作为单独的项目保存将更容易管理。
答案 1 :(得分：2)
好吧，例如我在我的应用程序中我分裂每个功能 - 例如我有模型链接 - 它被拆分为单独的模块以具有良好的应用程序结构，其中每个功能是分离的模块。这就像在加载器中加载更少的类。因为你只需要每个模块的模型和路由来加载整个应用程序，然后在模块中加载librarys / controllers / helpers / services等其他东西。