开发规范

花卉宝

常用的增删改查

service和class层都有以下通用方法可以使用

增
::add($data)
::batchAdd($data)

删
::deleteById($id)
::deleteByCondition($condition)

改
::updateById($id,$data)
::updateByIds($ids,$data)
::updateByCondition($condition,$data)

查
::getById($id,true)
::getByCondition($condition,true);
::getAllByCondition($condition,$order,$field,$indexBy)
::getByIds($ids,$order,$indexBy)
::getCount($condition)

::getList()
::getLimitList()
::getAllList()
condition支持查询条件包括
'name'=>'john'
'id>'=>3
'id<'=>10
'id'=>['in',[10,11,12]
'age'=>['between',[20,30]
'name'=>['like','Jack']

命名规范

###### 我们的数据库表和文件都使用驼峰式的。

对于助手类文件，在TP里命名为：Helper。我们这里诸多技术沿用新浪，命名规范也就沿用。助手和工具类文件我们命名以until为结尾。通用的为util，数组类为arrayUtil，字符处理的为stringUtil，以此类推。

调试方法

###### Yii自带debug，它对每一次的请求，参数，插入数据库都有记录，很好进行跟踪。在域名尾巴增加个debug即可使用，如：http://a.huaml.com/debug

三级分层设计

###### 为了保证整个技术设计能适应未来业务的发展，并且尽可能的提高代码复用，减少重复工作。

我们的项目结构分为：app和biz层

app主要是对外提供http接口 biz主要提供service接口给app层调用

biz层分为：service class model三层

各层的调用关系如下： app层可以调用biz层的service service可以调用class 同级之间可以互相调用，如user模块的serice可以调用order模块的service，class同理但底层不能调用上层，class不能调用serivce

我们平时大量的工作，在做重复的增删改查代码开发，为减少这块无谓的浪费，我们在service层封装了常用的增删改查操作。具体可查看【常用的增删改查】如果你在工作中也总结出一些可以复用的方法，也可以封装进去。

尽量保证service层的任何操作都有经过class层。未来我们要统一增加缓存，或者service层很多地方都有创建用户的方法，当我们要增加新东西时，只要在class增加一次就好这就是为什么我们封装的service层的增删改查，都有经过class层的增删改查。百川奔流终要归海。

前期开发的时候你会发现class有点多余，但业务越来越复杂时，你就会发现class层的价值

因为分层比较深，对一些各层都要使用到的参数，我们不必一直往下传。只要在最顶层设置一个全局的变量，底下各层各方法都可以调用。

Yii::$app->params['userId'] = 1;
Yii::$app->params['merchantId'] = 12358;

注释规范

开发功能，修改BUG，在别人代码上增加代码，都需要写明事项、修改人和时间。
如：查询方法的优化 shish 2019.9.21

统一输入输出格式

正确与错误输出：
//错误状态输出
util::fail('名称未填写');
//只输出成功状态
util::ok();
//输出成功状态并带数据
util::success(['userId'=>1],'操作成功');

分页：
page 第几页
pageSize 每页显示数
count 总数

guide.md 3.3 KB Histórico Raw