写在了路由表里，不知道这样合适不。
回复 (14)
J
我觉得可以的；不过我个人习惯在业务层才校验参数；再说你这里只校验了邮箱，没有校验密码；还有就是这个checkSignup复用性低，没必要这样写吧
M
引用 jacksparrow68我觉得可以的；不过我个人习惯在业务层才校验参数；再说你这里只校验了邮箱，没有校验密码；还有就是这个checkSignup复用性低，没必要这样写吧
@jacksparrow68 我这个只是写的一个思路，不晓得该不该这样写，所以只写了部分代码。
J
参数校验我觉得可以在业务层封装一个通用的方法，接受参数列表，根据校验规则循环校验
M
引用 jacksparrow68参数校验我觉得可以在业务层封装一个通用的方法，接受参数列表，根据校验规则循环校验
@jacksparrow68 就是controller里面吗？
J
引用 miuqiang@jacksparrow68 就是controller里面吗？
@miuqiang 是的。
M
引用 jacksparrow68@miuqiang 是的。
这个是别人大神写的，我不是很明白
P
引用 miuqiang这个是别人大神写的，我不是很明白
@miuqiang 这个参数校验有必要用promise包起来吗？多此一举啊
B
引用 miuqiang这个是别人大神写的，我不是很明白
@miuqiang 这个检验，狂秀代码，强行增加代码复杂度？
M
引用 peasonlee@miuqiang 这个参数校验有必要用promise包起来吗？多此一举啊
@peasonlee 这个是别人写的，我不太明白
M
引用 bs32g1038@miuqiang 这个检验，狂秀代码，强行增加代码复杂度？
@bs32g1038 你说我那个还是promise那个？
J
宁愿你用原始的validator啥也不封装，也别用这种写法；本来参数校验就没有异步回调，用promise包装会使得代码在一下一个时间片才继续往下执行
A
参数校验如果没有框架兜底的话，最好把校验的过程写进业务流程里面。
这样方便抽象，把框架依赖度降到最低，这样当你想切换框架的时候，基本就是低成本了
我是见过把逻辑跟框架强耦合的，结果想换框架的时候就...
M
I
引用 miuqiang这个是别人大神写的，我不是很明白
@miuqiang 强行promise 第一次见 哈哈哈哈哈哈哈
参与回复
登录后即可参与回复。登录