时间:2021-07-01 10:21:17 帮助过:30人阅读
还是MVC结构;
框架只包含路由、DB封装以及验证类(适合国情的手机号码、身份证、邮箱验证等);
干一件事,只有一种方式;比如很多框架会提供很多种方法来从数据库取一条记录,这个框架只有一种方法,比如只有find(Array $where)来取一条数据,没有其他封装方法,除非你用底层方法query;
API风格统一,类、方法、变量命名格式统一;
框架基础类继承不超过3层,你可以很容易地看懂框架源代码;
swiftmailer等国外成熟的类库直接通过composer加载即可使用,其他手动加载的类库放在library下面;
还有什么,大家继续补充。。。
框架目录结构:
├── composer.json
├── composer.lock
├── config //配置文件夹
│ └── main.php
├── controllers //控制层
│ └── UserController.php
├── library //第三方类库
│ └── weibo
├── models
│ ├── dao //数据访问对象层,封装SQL操作为相应的对象方法
│ │ └── User.php
│ └── data //业务控制层,封装业务逻辑,可以调用dao层、data层
│ └── User.php
├── public //web访问目录
│ └── index.php
├── vendor //composer仓库目录
└── views //视图层
└── user
└── info.php
框架设计目标:
还是MVC结构;
框架只包含路由、DB封装以及验证类(适合国情的手机号码、身份证、邮箱验证等);
干一件事,只有一种方式;比如很多框架会提供很多种方法来从数据库取一条记录,这个框架只有一种方法,比如只有find(Array $where)来取一条数据,没有其他封装方法,除非你用底层方法query;
API风格统一,类、方法、变量命名格式统一;
框架基础类继承不超过3层,你可以很容易地看懂框架源代码;
swiftmailer等国外成熟的类库直接通过composer加载即可使用,其他手动加载的类库放在library下面;
还有什么,大家继续补充。。。
框架目录结构:
├── composer.json
├── composer.lock
├── config //配置文件夹
│ └── main.php
├── controllers //控制层
│ └── UserController.php
├── library //第三方类库
│ └── weibo
├── models
│ ├── dao //数据访问对象层,封装SQL操作为相应的对象方法
│ │ └── User.php
│ └── data //业务控制层,封装业务逻辑,可以调用dao层、data层
│ └── User.php
├── public //web访问目录
│ └── index.php
├── vendor //composer仓库目录
└── views //视图层
└── user
└── info.php
这个嘛。已经有了,GitHub.com/dangcheng/scene-php
不错,思路清晰,化繁为简,很有实施性。
不过 看起来好像一个 CI 的升级版
我最近也在思考一个框架,既然这样我觉得我可以探讨一下,你思考是这样,但是写着写着你就发现可能不止三层了,我用了一段时间的Yii框架,觉得Yii框架包含的设计模式思想非常的好,开发起来整个逻辑很清晰。
我最近思考的一种方式就是后端只干后端的事情,纯数据处理,不进行渲染,只提供API,前端就只处理前端的事情,渲染完全靠前端JavaScript来做。
我觉得这种应该是App的设计思想。
移动端和pc端的适配怎么做呢? 如pc端数据可能是10个字段,但是移动端只需要查3~4个字段, pc端一个页面30条数据或者更多,移动端一页10来条