# thinkphp5_lib

**Repository Path**: 1620428040/thinkphp5_lib

## Basic Information

- **Project Name**: thinkphp5_lib
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2019-08-10
- **Last Updated**: 2020-12-16

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 模块应用
- 这个应用用来存放独立出来的基础功能
- 好处
    - 尽可能重用基础模块，避免重复开发
    - APP的页面和接口需要频繁重构
    - 避免跟APP应用的模块名称冲突
- 跨应用调用
    - APP应用可以直接调用模块应用中的功能
    - 模块应用不应该调用APP应用中的功能

## 应用目录
- `module`

## 入口文件
- `public/module.php`
    - 打开测试页面和接口，用于测试
- `public/notify.php`
    - 第三方服务器回调入口
- `public/index.php`
    - 添加一行`Loader::addNamespace("module",__DIR__."/../module/");`，使APP应用可以调用module应用的库文件

## 配置文件
- `config/module.php`
    - 设置加载模块相关的参数，在使用不同版本的框架时可以灵活调整配置

## 文件读写权限设置
- `public/uploads`
    - 用户上传文件目录

## 第三方服务
| 服务 | 整合模块 | 下属模块 | 备注 |
| :-: | :-: | :-: | :-: |
| 登录 | user | alipay/wechat/qq/wxwork | 是否要放到单独的模块`user_outside`中
| 支付 | account | alipay/wxpay | 
| 消息 | notice | | 包括短信、邮件、消息推送，未开发


## 问题
- 添加访问控制模块引发的问题
    - 问题在于
        - 如何设置基础模块的依赖关系
            - 现在的依赖关系是
                - common之类的必须模块，不依赖install
                    - install
                        - cron之类的与用户无关的模块，不依赖user
                        - user
                            - access
                                - account
                            - api
                            - menu
        - 很多上层模块依赖的`BaseController`该放在哪个模块
            - 现在`BaseController`在用户模块中
    - 问题是
        - 访问控制需要使用的范围更大
        - 要将其他模块也修改成依赖访问控制模块很麻烦
        - 类似访问控制这种模块可能被移除
    - 解决思路
        1. 将访问控制模块作为更基础的模块，作为用户模块的基类，并且允许不使用访问控制
            - 这也需要实现模块的相关模块功能
            - 如果还需要添加其他功能的话，用户模块会变得过于复杂
        2. `BaseController`增加扩展功能，当被调用到不存在的方法时，查找扩展中的方法
            - 其他模块，比如access可以作为扩展，比如`checkRole`方法，作为`check`类的扩展
            - 缺点
                - 有点复杂
                - 不好写注释
                - 上层模块必须知道有这个功能才能使用
                - 下层模块已移除会导致bug，这个问题可以通过`check`类的扩展方法默认返回true来解决，但会更麻烦
        3. 添加一个`base`模块，替代`user`作为上层模块的基类
            - 添加新的基础模块时，在`base`模块中增加方法
            - 缺点是需要频繁修改`base`模块
            - 而且base模块下层的模块不能调用base模块的方法
        4. 从`access`中分离出一个`user_access`作为user的上层，`access`本身作为下层
            - `user_access`还是会有与`user`相互依赖的问题
        5. 将`common`作为一个特别的模块
            - 不算入依赖关系中，或者说仍然作为所有模块的基类
            - 允许其预留一些方法接口，如果需要的模块已安装，则调用已安装的功能；如果未安装，则返回默认值
    - 解决方式
        - 从`access`中分离出一个`user_access`作为user的上层，`access`本身和`user`是平行的，且不关联
        - 将`common`作为一个特别的模块，可以随意调用`user`/`access`中的功能