framework.php
1.0.0
This is a framework for small and medium-sized team development
A simple personal blog bybzmt/blog.php
Personal blog bybzmt/blog.php based on this framework has very powerful performance
| model | Static files | Home (2 blogs) | Home (10 blogs) |
|---|---|---|---|
| Fpm | 4705 | 1507 | 1237 |
| Swoole | 26607 | 3276 | 2084 |
├── assets 资源目录(如:字体文件等)
├── config
│ ├── dev 开发环境配置
│ ├── product 生产环境配置
├── index.php 项目入口
├── library 其它与composer不兼容的库
├── src
│ ├── Admin 管理后台
│ ├── Api app接口端
│ ├── Backend 内部(内网)接口
│ ├── Common 公共代码目录
│ ├── Console 控制台
│ ├── Wap 手机Web端
│ └── Web Web端
├── static
│ ├── admin 后台静态文件
│ └── web Web端静态文件
├── tests 单元测试目录
├── var 可读写目录(如:模板缓存等)
└── vendor composer库
Since Swoole is a resident memory mode, the life cycle of global variables is application-level, and unlike fpm mode, it is only request-level. Global variables can be maintained between different requests, so the original methods such as $_GET and $_POST cannot be used. This framework instantiates a Context object for each request and stores all data related to the current request into the Context object.
The Context object is also responsible for component loading and replacing functions at hierarchy.
As in the above blog:
When initializing the component, the Context object will first look for the corresponding component in its namespace. If it is not found, the parent Context will be initialized. This way, it can easily expand and replace the components you need.
api:
Request object is a swoole_http_request that is used directly
Response objects also use swoole_http_response directly
In Fpm mode, the framework implements a compatibility layer to maintain the same API as in Swoole
The framework implements all objects related to Context objects as Component, mainly to provide fast instantiation functions, and does not require repeated transmission of Context objects.
In addition, Component also has some convenient methods to use in any component.
Railing does not adopt open mapping, but uses registered routing, with the advantage of being relatively clean.
The routing project is located in bybzmt/router.php
If you don't like it, you can replace it with the library you like, and it's very easy to replace the components of the framework.
The framework recommends using the domain model pattern, using: Service, Table, Row(Domain) structure
It should be noted that data display work should not be written into Service, Table, and Row. It is only responsible for providing the most basic data. Organizing the corresponding data structure according to page and API requirements should be implemented in controllers and views.
The database is divided into Table class that provides basic functions and TableSplit class that provides table functions. There is also a TableRowCache trait that provides caching function. Any user's table should be inherited from the Table or TableSplit class, and when cache is required, it can be introduced.
Note that both the table and cache only support the get/gets/insert/update/delete operations in the Table class. When using SQL to directly perform data operations, you need to manually maintain relevant cache or table functions.
The framework provides a LazyRow loading method. When instantiating, it only records the id and then attempts to load in batches until the attribute is accessed.
The framework provides some common functions and is convenient to use
This cache has nothing to do with the cache in the table above, it refers to the cache maintained by the user. Try to let different types of caches be managed with different classes to avoid key conflicts.
The framework does not provide template functions, and it is recommended to directly make existing third-party template programs. (For example: Twig)
The functions of the framework do not want to adapt to all environments, they only need to be available in 80% of the cases. Special circumstances can be handled specially in specific projects.
There is not much code in the framework, so try to read all the code as much as possible.
