api接口怎么写_面向声明式API编程（DAP）

DAP是Mars-java 最近提出的一个新的开发方式，全称 Declarative API Programming，提倡后端为一个独立的整体，不应该是为前端服务的，所以当前端需要接口的时候，只需要声明一个API给他，而不需要专门开发一个Controller出来

面向声明式API编程(DAP)

按照传统的开发方式，如果要开发一个后端接口，需要分为以下三步

创建controller
创建service
创建dao（甚至会创建存放sql的xml）

但是，我们编写一个接口，重点应该是放在业务逻辑上的，也就是说我们的关注点应该在第二步，但是通常第一步和第三步的重复工作量让我们感到窒息，所以我梳理了一下，制定了一个新玩法，这套新玩法就叫声明式API

写业务逻辑
声明一个API给前端
将API与业务逻辑关联

所以我们是这样玩的

编写业务逻辑

@MarsBean("testService")
public class TestService {要返回的数据类型 selectListForName(参数1, 参数2, 参数3, 参数4){// 第一步 根据testDTO里的参数从xx表查询需要的数据// 第二步 根据查出来的数据，去操作xx2表// 第三步 对前两步的结果汇总，进行xxx操作return 数据（直接返回即可，会自动变成json）；}
}

声明一个API接口

@MarsApi
public interface TestApi {Object selectList(TestVO testVO);
}

将api与业务逻辑关联

@MarsApi
public interface TestApi {@MarsReference(beanName = "testService",refName = "selectListForName")Object selectList(TestVO testVO);
}

对，你没看错，API的方法和他引用的那个方法，参数列表可以不一样，框架会自动把API的参数的值赋值到引用的那个方法的参数列表

引用的方法甚至可以无参，参数目前只支持自定义对象和Map

这套思想的核心是，把后端看作是一个独立个体，并不是为服务前端而存在的，后端就写后端的业务逻辑好了，如果前端需要数据，那我们就开个门给他

这么做的好处，还可以散藕

通过更换MarsReference的配置，可以关联到不同的业务逻辑
如果前端不需要这个接口了，直接无脑删就好了，因为这只是一个抽象方法
后端专注业务逻辑就好了，不需要考虑跟前端互动，前端需要的时候开个门就好了

接下来怎么做

看到这里，大家肯定会有疑问，前端要怎么调用api，后端怎么操作数据库？这个就需要你们动动手指，去我的官网一探究竟

还可以做什么

首先声明式API是对前后端交互方式的一次变革，省去了Controller。

其实这种风格在微服务里很常见，比如Dubbo的api，既然微服务接口可以用interface来提供对外的服务，那么我们也可以把它用到http接口上吧。

很多java初学者在刚接触分层架构的时候，肯定有过疑问，Service是干嘛的，因为在某些场景下，这层跟DAO是很像的，而以后，他们再也不会有这种疑问了

除了声明式API，我们还提供以下功能

单表操作和固定sql操作，仅需一行注解
分页仅需调用一个方法，没有任何第三方依赖
没有像Mybatis一样的sqlMapper.xml
支持AOP,IOC,声明式事务
搭建仅需三步，并提供官方中文文档，再也不需要满大街的搜Spring的机翻文档或者个人博客了

实体类的争议

本框架是强制要求，DAO用来接数据的实体类，字段名必须和表的字段名一致的，这样虽然提高了耦合，但是减少了映射的配置，并且实际情况是，如果你用别的框架，你改了数据库的字段名，你一样要去改配置映射的那部分代码，所以用映射来降低耦合并没起到什么作用

不过争议不再这一点上，而在于命名规范上，因为数据库的字段名通常是下划线分割单词，跟java的变量名常用的驼峰有点出入，首先可以确定的是JVM官方对变量名的命名规范是支持用下划线的，并且常量都是这么做得，从没出现过风险。

所以我总结了以下观点

是全英文命名
可读性完全没影响
不管是编译还是运行都不会存在风险
只是DAO返回的实体类用这种命名，并非所有的变量都要遵守

所以，我们为什么非要一成不变的把自己关在旧笼子里？

如果实在无法接受，我们也提供了解决方案，那就是用Map，然后在DAO层手工转换成你的实体类。

官网

http://mars-framework.com

收藏 (1) 分享