在服务端进行控制是否允许跨域，可自定义规则
• 支持各种请求方式
  缺点：
• 会产生额外的请求

我们这里会采用cors的跨域方案。

4.2.4 cors解决跨域

4.2.4.1 什么是cors

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。

它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

• 浏览器端：
  目前，所有浏览器都支持该功能（IE10以下不行）。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
• 服务端：
  CORS通信与AJAX没有任何差别，因此你不需要改变以前的业务逻辑。只不过，浏览器会在请求中携带一些头信息，我们需要以此判断是否运行其跨域，然后在响应头中加入一些信息即可。这一般通过过滤器完成即可。

4.2.4.2 原理

浏览器会将ajax请求分为两类，其处理方案略有差异：简单请求、特殊请求。

简单请求

只要同时满足以下两大条件，就属于简单请求。：

（1) 请求方法是以下三种方法之一：

• HEAD
• GET
• POST

（2）HTTP的头信息不超出以下几种字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

当浏览器发现发现的ajax请求是简单请求时，会在请求头中携带一个字段：Origin.

Origin中会指出当前请求属于哪个域（协议+域名+端口）。服务会根据这个值决定是否允许其跨域。

如果服务器允许跨域，需要在返回的响应头中携带下面信息：

Access-Control-Allow-Origin: http://manage.leyou.com
Access-Control-Allow-Credentials: true
Content-Type: text/html; charset=utf-8

• Access-Control-Allow-Origin：可接受的域，是一个具体域名或者*，代表任意
• Access-Control-Allow-Credentials：是否允许携带cookie，默认情况下，cors不会携带cookie，除非这个值是true

注意：

如果跨域请求要想操作cookie，需要满足3个条件：

• 服务的响应头中需要携带Access-Control-Allow-Credentials并且为true。
• 浏览器发起ajax需要指定withCredentials 为true
• 响应头中的Access-Control-Allow-Origin一定不能为*，必须是指定的域名

特殊请求

不符合简单请求的条件，会被浏览器判定为特殊请求,，例如请求方式为PUT。

预检请求

特殊请求会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

一个“预检”请求的样板：

OPTIONS /cors HTTP/1.1
Origin: http://manage.leyou.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.leyou.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

与简单请求相比，除了Origin以外，多了两个头：

• Access-Control-Request-Method：接下来会用到的请求方式，比如PUT
• Access-Control-Request-Headers：会额外用到的头信息

预检请求的响应

服务的收到预检请求，如果许可跨域，会发出响应：

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://manage.leyou.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

除了Access-Control-Allow-Origin和Access-Control-Allow-Credentials以外，这里又额外多出3个头：

• Access-Control-Allow-Methods：允许访问的方式
• Access-Control-Allow-Headers：允许携带的头
• Access-Control-Max-Age：本次许可的有效时长，单位是秒，过期之前的ajax请求就无需再次进行预检了

如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理是一样的了

4.2.4.3 实现

• 浏览器端都有浏览器自动完成，我们无需操心
• 服务端可以通过拦截器统一实现，不必每次都去进行跨域判定的编写。

事实上，SpringMVC已经帮我们写好了CORS的跨域过滤器：CorsFilter ,内部已经实现了刚才所讲的判定逻辑，我们直接用就好了。

在ly-gateway中编写一个配置类，并且注册CorsFilter：

@Configuration
public class GlobalCorsConfig {
@Bean
public CorsFilter corsFilter() {
//1.添加CORS配置信息
CorsConfiguration config = new CorsConfiguration();
//1) 允许的域,不要写*，否则cookie就无法使用了
config.addAllowedOrigin("http://manage.leyou.com");
//2) 是否发送Cookie信息
config.setAllowCredentials(true);
//3) 允许的请求方式
config.addAllowedMethod("OPTIONS");
config.addAllowedMethod("HEAD");
config.addAllowedMethod("GET");
config.addAllowedMethod("PUT");
config.addAllowedMethod("POST");
config.addAllowedMethod("DELETE");
config.addAllowedMethod("PATCH");
// 4）允许的头信息
config.addAllowedHeader("*");
// 5) 有效时长
config.setMaxAge(3600L);

//2.添加映射路径，我们拦截一切请求
UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
configSource.registerCorsConfiguration("/**", config);

//3.返回新的CorsFilter.
return new CorsFilter(configSource);
}
}

重新访问，ok！

4.3 实现品牌查询

4.3.1 brand数据表

CREATE TABLE `tb_brand` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '品牌id',
`name` varchar(50) NOT NULL COMMENT '品牌名称',
`image` varchar(200) DEFAULT '' COMMENT '品牌图片地址',
`letter` char(1) DEFAULT '' COMMENT '品牌的首字母',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=325400 DEFAULT CHARSET=utf8 COMMENT='品牌表，一个品牌下有多个商品（spu），一对多关系';

由于品牌和商品分类之间是多对多关系。因此我们有一张中间表，来维护两者间关系

CREATE TABLE `tb_category_brand` (
`category_id` bigint(20) NOT NULL COMMENT '商品类目id',
`brand_id` bigint(20) NOT NULL COMMENT '品牌id',
PRIMARY KEY (`category_id`,`brand_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品分类和品牌的中间表，两者是多对多关系';

但是，你可能会发现，这张表中并没有设置外键约束，似乎与数据库的设计范式不符。为什么这么做？

• 外键会严重影响数据库读写的效率
• 数据删除时会比较麻烦

我们在代码中通过逻辑来维护表关系，不设置外键。

4.3.2 brand实体类

@Data
@Table(name = "tb_brand")
public class Brand {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;// 品牌名称
private String image;// 品牌图片
private Character letter;
}

4.3.3 业务

4.3.3.1 web

4.3.3.1.1 页面分析

• 请求方式：查询，肯定是Get
• 请求路径：分页查询，/brand/page
• 请求参数：根据我们刚才编写的页面，有分页功能，有排序功能，有搜索过滤功能，因此至少要有5个参数： page：当前页，int
• rows：每页大小，int
• sortBy：排序字段，String
• desc：是否为降序，boolean
• key：搜索关键词，String

total：总条数
• items：当前页数据
• totalPage：有些还需要总页数

这里我们封装一个类，来表示分页结果：

@Data
public class PageResult<T> {
private Long total;// 总条数
private Long totalPage;// 总页数
private List<T> items;// 当前页数据

public PageResult() {
}
public PageResult(Long total, List<T> items) {
this.total = total;
this.items = items;
}
public PageResult(Long total, Long totalPage, List<T> items) {
this.total = total;
this.totalPage = totalPage;
this.items = items;
}
}

这个PageResult以后可能在其它项目中也有需求，因此我们将其抽取到ly-common中，提高复用性：

我们只需在ly-item-service中引用ly-common依赖即可（在上述已经引过了）

4.3.3.1.2 实现业务

@RestController
@RequestMapping("brand")
public class BrandController {

@Autowired
private BrandService brandService;

// 分页查询品牌
@GetMapping("page")
public ResponseEntity<PageResult<Brand>> queryBrandByPage(
@RequestParam(value = "page" , defaultValue = "1") Integer page,
@RequestParam(value = "rows" , defaultValue = "5") Integer rows,
@RequestParam(value = "sortBy" , required = false) String sortBy,
@RequestParam(value = "desc" , defaultValue = "false") boolean desc,
@RequestParam(value = "key" , required = false) String key

){
return ResponseEntity.ok( brandService.queryBrandByPage(page,rows,sortBy,desc,key));
}
}

@RequestParam注解：获取参数

主要参数：

• value

  ：参数名字，即入参的请求参数名字，如username表示请求的参数区中的名字为username的参数的值将传入；

• required

  ：是否必须，默认是true，表示请求中一定要有相应的参数，否则将报404错误码；

• defaultValue

  ：默认值，表示如果请求中没有同名参数时的默认值

在SpringMVC后台控制层获取参数的方式主要有两种:

• request.getParameter("name")

• 注解

  @RequestParam

  直接获取

RequestParam

@PathVariable注解：绑定URI模板变量值

• @PathVariable

  是用来获得请求url中的动态参数的

• @PathVariable

  用于将请求URL中的模板变量映射到功能处理方法的参数上。
  //配置url和方法的一个关系@RequestMapping(“item/{itemId}”)

@RequestParam

和

@PathVariable

都能够完成类似的功能——因为本质上，它们都是用户的输入，只不过输入的部分不同，一个在URL路径部分，另一个在参数部分。

   通过

@PathVariable，例如/blogs/1

   通过

@RequestParam，例如blogs?blogId=1

4.3.3.1 service

@Service
public class BrandService {
@Autowired
private BrandMapper brandMapper;

// 分页查询品牌
public PageResult<Brand> queryBrandByPage(Integer page, Integer rows, String sortBy, boolean desc, String key) {
//分页
PageHelper.startPage(page,rows);

//过滤: 过滤条件(模糊查询+准确查询(首字母))
Example example = new Example(Brand.class);
if(StringUtils.isNotBlank(key)){
example.createCriteria().orLike("name","%"+key+"%").orEqualTo("letter",key.toUpperCase());
}

//排序
if(StringUtils.isNotBlank(sortBy)){
String orderByClause = sortBy + (desc ? " DESC" : " ASC"); //注：" DESC"，DESC前有空格
example.setOrderByClause(orderByClause);
}

//查询
List<Brand> list = brandMapper.selectByExample(example);
if(CollectionUtils.isEmpty(list)){
throw new LyException(ExceptionEnum.BRAND_NOT_FOUND);
}

//解析分页结果
PageInfo<Brand> pageInfo = new PageInfo<>(list);
return new PageResult<>(pageInfo.getTotal(),list);
}
}

• 分页

  pagehelper：通过配置了一个

  mybaits

  拦截器，拦截到

  PageHelper.startPage(page, rows)

  ;之后第一个查询语句，然后将其拼接成不同的

  sql

  再进行查询。

过滤

将

Brand.class

字节码文件传给

Example

，通过反射机制得到实体类中的表的名字，主键等信息。

• example.createCriteria().orLike("name","%"+key+"%").orEqualTo("letter",key.toUpperCase())

  动态拼接

  sql

  语句

排序

example.setOrderByClause(orderByClause)

;


ORDER BY

关键字是可以自动生成的，重点是后面的 根据什么排序 sql语句不知道，所以要写一个orderByClause——排序子句
注意： " DESC" : " ASC"关键字前要有空格。

查询

List list = brandMapper.selectByExample(example);

解析分页结果

PageInfo<Brand> pageInfo = new PageInfo<>(list)

;

return new PageResult<>(pageInfo.getTotal(),list)

;

分页助手会对

list

Page对象

4.3.3.1 mapper

public interface BrandMapper extends Mapper<Brand> {
}

4.4 实现品牌新增

4.4.1 web

4.4.1.1 页面分析

• 请求方式：由前端页面看出是POST
• 请求路径：/brand
• 请求参数：brand对象，外加商品分类的id数组cids
• 返回值：无

4.4.1.2 实现业务

// 品牌新增
@PostMapping
public ResponseEntity<Void> saveBrand(Brand brand,@RequestParam("cids")List<Long> cids){
brandService.saveBrand(brand,cids);
return ResponseEntity.status(HttpStatus.CREATED).build();//无返回体选择build
}

4.4.2 service

这里要注意，我们不仅要新增品牌，还要维护品牌和商品分类的中间表。

// 品牌新增
@Transactional
public void saveBrand(Brand brand, List<Long> cids) {
//新增品牌
brand.setId(null);//初始设置成null，新增之后回显
int count = brandMapper.insert(brand);
if(count != 1){
throw new LyException(ExceptionEnum.BRAND_NOT_FOUND);
}
//中间表新增。但是中间表没有实体类，没有通用mapper
for (Long cid : cids){
count = brandMapper.insertCategoryBrand(cid,brand.getId());
if(count != 1){
throw new LyException(ExceptionEnum.BRAND_NOT_FOUND);
}
}
}

这里调用了brandMapper中的一个自定义方法，来实现中间表的数据新增。

@Transactional注解

• 在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中
• 声明式事务管理也有两种常用的方式，一种是基于tx和aop名字空间的xml配置文件，另一种就是基于@Transactional注解
• 当作用于类上时，该类的所有 public 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义
• 如果被注解的数据库操作方法中发生了unchecked异常，所有的数据库操作将rollback

4.4.3 mapper

通用Mapper只能处理单表，也就是Brand的数据，因此我们手动编写一个方法及sql，实现中间表的新增：

public interface BrandMapper extends Mapper<Brand> {
/**
* 新增商品分类和品牌中间表数据
* @param cid 商品分类id
* @param bid 品牌id
* @return
*/
@Insert("INSERT INTO tb_category_brand (category_id, brand_id) VALUES (#{cid},#{bid})")
int insertCategoryBrand(@Param("cid") Long cid, @Param("bid") Long bid);
}

4.5 图片上传

由于上传在很多微服务中都可能需要，因此我们将其创建为一个独立的微服务，专门处理各种上传：上传服务

注：由于商品微服务内容太多，所以做了优化，拆分成两部分写。地址：商品微服务–后半部分