现在项目所用的是 RESTful 风格开发,也就是全部都是 api 路由绑定对应的控制器。现在就有一个问题,例如在 A 控制器中,想要调用 B 控制器中的中的某个方法来完成一定的逻辑,由于控制器方法绑定路由,参数的接受方式全都是$_POST 或者$_GET 的方式获得的,所以我只能通过模拟 POST 或 GET 请求,走路由,然后才能调用到该方法。
1
xupefei 2015-08-19 23:04:34 +08:00
写一个公用函数, A 和 B 都去调用它。
|
2
luban 2015-08-20 00:11:41 +08:00 via Android
b 控制器中不该有太多方法的实现,你该独立出一个 service 层,等等, service 不该操作数据库,你该独立出一个 dao 层,等等, JAVA 为什么要这么多层
|
3
iyaozhen 2015-08-20 00:19:36 +08:00
我觉得你应该分一下层,数据层控制器 A 、 B 都可以去调用。若是 A 中需要用到 B 中的方法(一般也是处理数据的方法),那么就把这个方法独立出一个库或者辅助函数。
|
4
matrixyuri 2015-08-20 00:47:10 +08:00
@luban
这个方法其实蛮好的,我目前框架里就是引入了这个思想, 分 Action (Controller ), Service, Data, View 四层, 其中 Service 和 Data 合起来就是原本的 Model 层。 Service 层负责封装 Data 层, Data 层负责原子性的数据增删改查,或者是获取网络内容什么的,互相之间杜绝相互调用。 具体的需求实现在 Service 里完成, Action 层只负责输入输出的校验逻辑,已经调用 Service 层函数。 我自己做的框架 [Vera]( https://github.com/MatrixYuri/Vera ) 欢迎 Fork 欢迎 PR 欢迎 Star~ |
5
dododada 2015-08-20 14:59:05 +08:00
mvc 很多年了
|
6
blue7wings OP @luban
@matrixyuri 把一定的功能实现放到 service 层去,那么控制器中应该抽象到什么程度,把 Request 请求的数据处理,然后数据的输出放在控制器中,中间所有的逻辑都放到了 service 中去,这样合不合理呢? |
7
matrixyuri 2015-08-21 02:47:48 +08:00
@blue7wings
就是你说的这样,把业务逻辑都放在 Service 里边, Controller 里边只做输入输出的校验容错。 这样的话,接口这里比较灵活,可以同一功能、根据不同的输入对应到不同的 URL 上。 另外对实现需求也比较灵活,比如今天 PM 说要有一个查看学生成绩的功能,就通过 Service 调取对应的 Data 层方法,汇总得到学生的成绩;明天 PM 说要把学生和老师对应起来,这时就可以复用昨天的 Data 层方法,在新的 Service 中融合进来老师的 Data 层数据,按照要求实现新的汇总数据。 简单的说就是把需求拆成独立的互不干扰的小功能点,便于之后根据新的需求进行组装。 这个思路目前一直在用,觉得挺好使的,可以轻松应对善变的 PM ,不容易出人命:) |
8
blue7wings OP @matrixyuri 谢谢你的回复,学到了。。
|
9
that24 2015-09-09 22:40:03 +08:00
@matrixyuri 请教下 Service 里面的版本怎么控制呢?比如 /v1/user/:id 调用 Service 里面的 User 类中的 Info 方法,当现在变成 V2 时如何控制比较好?
|
10
matrixyuri 2015-09-10 14:12:37 +08:00
@that24
如果业务逻辑方面没变化,就可以复用原本的 Service , 如果有变化,就实现一个新的 Service ,通过新的 Controller 调用。 命名的话,可以考虑 Service_Aa 作为 v1 , Service_Ab 作为 v1.1 , Service_Ba 作为 v2 这样。 |