什么时候我们应该在php中使用多模块结构(而不是简单结构) Phalcon[英] When should we use multi-module structure (instead simple structure) in php Phalcon

问题描述

什么时候应该在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 也有同样的问题!

推荐答案

如果你正在构建一个单一用途的应用程序作为不使用视图的 API,你应该使用单模块结构.如果它是一个非常简单的 API,例如存储/记录,微应用也可以.

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

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

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

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

更新

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

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

本文地址:https://www.itbaoku.cn/post/1739761.html

相关标签/搜索