后端实现的主要考虑

当api设计确定以后，剩下的工作就是实现了。我跳过架构和设计这两个环节，因为用了Rails框架之后，这两个环节的工作简而又简。加之项目本身在前期并不庞大，还不需要过多的设计。

首先介绍一下Rails框架的基本结构吧。Rails框架是一款用Ruby开发的后端MVC框架，由于我只是开发API应用，其中的View层就被我无端地简化了。我的重点工作只剩下定义Model层和实现Controller层即可，最终是在Controller层返回JSON数据，没有显示地定义视图。一个Rails应用的目录结构如下：

　　app/    - 应用主目录

　　　　controllers/  - 控制器所在目录

　　　　models/       - 模型所在目录

　　config/ - 配置所在目录

　　　　routes.rb     - 路由配置文件

　　　　mongoid.rb - MongoDB数据库配置文件

其实还有其他的目录，只是我没说而已。Rails框架很自然地为你规定好项目的基本结构，我剩下的工作就是往里面填自己的代码。这一过程大体是：

1. 在app/models下面定义自己的Model（我之前说过，我用的是Mongoid为MongoDB数据库的collection定义模式）

2. 在app/controlles下面定义自己的Controller。这里面，Controller的任何方法都可以配置为API接口的处理方法。Controller的方法大致就是处理前端的API请求逻辑，有时不可避免地要调用Model层的一些东西。

3. 在routes.rb中配置API与Controller中的方法的映射关系。

不过，虽说是填代码，但还是要有很多要考虑的地方。

DRY：Don't Repeat Yourself

我把它视为首要的考虑。如果项目中存在重复代码，就可以看成存在设计缺陷。

一个典型的例子是这样的：我之前说过，我的API设计中存在分页（from，size），sort，include，with_total，just_total等控制，其中from，size，sort是Model查询时的控制参数，include，with_total, just_total是作为返回JSON数据时的控制参数。我的所有List接口，即形如GET /users这样的接口都是有这些控制参数的。这其中要进行如下处理：

1 from, size = 合适的值，用于分页2 sort = 将params[:sort]转化成能被Model识别的形式3 cond = 将params[:cond]转化为能被Model识别的形式4 users = User.where(cond).order(sort).limit(size).offset(from)5 includes = 将params[:include]转化为能够被as_json识别的形式6 list = 基本就是users.as_json(includes), 但还要处理with_total,just_total的情况7 render json: list

海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com

原标题：后端实现的主要考虑

关键词：