网站首页 文章专栏 个人项目解耦----封装composer包

个人项目解耦----封装composer包

编辑时间:2020-07-09 15:04:37 作者:苹果 浏览量:146


    前言:当一个项目越做越大,或者自己的项目越写越多,势必出现大量代码的重复书写,冗余且无趣,甚至可能因为修改了自己项目的某行代码,导致别人的报错,免不了一顿毒打。此时,代码解耦,分开管理就体现出其价值所在。


我个人尝试过两种代码解耦: 以服务器为依托的根据功能拆分的封闭式 微服务结构  和 以composer包为依托的开源闭包结构。

1.以服务器为依托的根据功能拆分的封闭式 微服务结构


   将某个功能部署在某个服务器上,通过指定的访问路径,定义好请求字段和返回字段,类似于我们请求第三方的接口一样。如果只限于对自己项目内部访问,建议与反向代理搭配使用,搭建内网体系,较少不必要的内部请求验证。
   优点:这个微服务由指定的人员维护,调用者不知道也不关心内部怎么处理的,只管调用就是了,拿到返回数据后,根据自己的业务逻辑做特定的转换处理,可以有效的保护数据库被非授权人员访问。可以根据该功能在项目中承担的访问比重,调节服务器的分配资源,尽可能使服务器达到最大化的合理应用。
   缺点:需要服务器数量较多,而且一旦此功能异常,势必导致其他项目异常,其本质还是集中管理,很有可能某台服务器的高并发请求。

2.以composer包为依托的开源闭包结构


    将某个特定的功能封装成一个composer包,暴露多个方法,能够处理些个功能,引入对应的composer包即可调用其中的方法。如果某个业务需要部署在多个平台上,此时可将整个业务做成一个项目包,配置各个项目的访问地址指向各自本地包的位置即可,完全不会对原本的项目有任何影响。
    优点:可移植性高,本地代码包自成体系独立运作,功能模块的包可能需要考虑场景较多,代码较多,但业务模块的代码只满足本业务需要即可。
    缺点:说到底还是本地安装代码,代码开源,所有有权限访问该项目代码的人均可获取包里的内容,包与包之间可能会存在依赖关系。


我个人能现下常使用的是后者,即composer包的管理模式。因为其可移植性和可扩展性,自己封装的功能包,能让自己一直复用,而且能在多个平台使用,互不影响。


建立一个属于自己的composer 功能包

1.创建并拉取一个远程的空的git 项目包

2.在本地git 包里创建自己的composer包
   1>简单的创建流程如下图

    composer_init.jpg


    建包中的各个参数详情,见composer 官网  https://docs.phpcomposer.com/


   2>
   在生成的composer.json 中配置自己的的命名空间映射
   eg:

        "autoload": {
              "psr-4": {
                  "bydls\\test\\": "src/",
              }
          }

    我这边是将bydls\test 的命名空间指向了src目录中

   


   扩展:如果要封装一个带有控制器或者可供http请求的包,只需将路由的命名空间指向这个包而已。



3.上传并拉取自己的composer包

   1>
   如果是只限允许的项目使用,则利用git的对私属性,将自己的包上传至对应的gittub地址,设置相应的ssh通道,然后在 composer.json中加入

   "repositories": {
            "bydls/test": {
                "type": "vcs",
                "url": "github地址"
            }
        }


       然后就可以正常的安装   composer  require bydls/test
   2>
   如果是作为一个开源的对公的的包,将自己的包上传至对应的gittub地址后,提交到packagist即可。   官网https://packagist.org/packages/submit

    然后就可以正常的安装   composer  require bydls/test


我个人的一个常用工具包 composer  require bydls/Utils


    出自:何冰华个人网站

    地址:http://www.hebinghua.com/

    转载请注明出处


来说两句吧
最新评论