我们什么时候应该在 php Phalcon 中使用多模块结构（而不是简单结构）？
我发现了一些多模块骨架，例如：
https://github.com/ovr/phalcon-module-sculpture https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple https://github.com/phalcon/mvc/tree/master/multiple.
但我不知道我应该在项目中使用这种多模块结构，而不是使用多个项目。
我可以想到的是：配置更复杂，文件夹结构更复杂，我的网址更长（/[模块]/[控制器]/[操作]），而且重要的是，性能会很低（加载的东西比更多） 。
不过，我认为它有一些有趣的地方（很多 ITer 都用过它）。有没有人可以告诉我优点、缺点和选择标准。
P/s：Zend2模块也有同样的问题！
如果您正在将单一用途的应用程序构建为不使用视图的 API，那么您应该使用单一模块结构。如果它是一个非常简单的 API，例如存储/日志记录，那么微型应用程序也可以。
如果您愿意构建更复杂的解决方案，多模块应用程序结构会很有用。例如，具有公共内容但具有管理面板的公共应用程序。这个可以很方便地编写多模块来将管理控制器/视图与那些公共控制器/视图分开。
我的习惯是使用多模块结构，因为大多数情况下我必须构建 CRM 应用程序及其 API 和公共可访问的内容部分（例如文档）。为了这个目的，创建这样的模块很方便：
-
frontend- 适用于每个人都可以访问的控制器
-
backend- 用于在身份验证和授权后可访问的控制器，例如管理事物
-
API- 用于 API 目的；）
-
common- 我宁愿不实现这一部分，但在一个项目中，我被迫在这里放置一些抽象控制器，这些控制器将在其他模块中扩展。
通过这种方式，您可以为每个模块保留单独的服务配置，从而避免切断您正在使用的模块的内容A，但不在模块上B。喜欢身份验证部分 - 对于backend，但没用frontend部分。或者数据库配置 - 前端的从站，后端的主站等。所以这对于大型项目来说可能也是一个性能明智的解决方案。
Update
有时“多项目”是一个选项，包括“多模块”项目；）这很大程度上取决于您想要实现的目标。例如。如果您将 API 拆开，在多个实例上扩展它可能会更容易，但首先您需要花费精力来配置单独的项目。
如果系统应该是单服务器实例或者每个实例都应该绝对独立于其他实例，那么单个多模块项目就足够了 - 比如说一个标准的 CMS、博客平台，甚至是简单的浏览器游戏或包括 API 的移动应用程序主页为了它。但是，如果您正在构建一整套应用程序，例如提供内容的内部 API、管理内容的 CRM 以及为其提供服务的几个网页，那么将它们保留为单独的项目将更易于以后管理。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
