今天完成的事情：利用联表查询完成学员报名系统，完成上传并更新头像的功能

首先这块板块的内容是受保护的，也就是/a/u开头，受拦截器检验cookie的

另外，我在session里面也加了一个名为name的attribute，对学员板块的操作除了对cookie的校验，对name的值又做了双重校验。这是因为name的值关系到学员模块的联表查询，必须保证其合法性（之所以dao的接口不用id，我觉得太危险，这样子做的话user板块的维护人员就可以为所欲为了，毕竟他不知道每一个用户的userName），controller的方法：

成功报名，回显的页面：

联表查询的dao层mapper：

dao的接口：

//通过用户名称获取关联的学员信息（懒加载）

User findStudentByName(String userName) throws Exception;

那话说回来，为什么要做联表查询呢？把有关联的这些东西直接放在一个表里不就行了吗？我仔细思考了下，暂时归纳出以下几点，不外乎就是性能和安全（权限）两个大方面（个人思考，可能有误）：

    * 1.减少数据库中表的宽度，提高查询效率

    * 2.当项目做大的时候，不同模块需要分开，好几台机器在跑，需要解耦（RMI）

    * 3.对开发/运营者的一个权限控制，因为底层的dao可以设置为只读的，比如我这里设置只能通过用户的名称才能修改学员信息

    * 4.（未实现）对数据库的管理者甚至都可以做一个权限控制，可以在Spring中配置多个数据源，从而将表存放在不同的数据库（甚至是不同机器）中

    * 关于第四点，可以参考：https://www.cnblogs.com/yougewe/p/7062998.html

    * 为什么需要懒加载：当这个表关联太多，业务功能较多的时候，不懒加载卡死你......

做出来的service层是这样子的，aotowired了两个dao：

那有人也许会问，那你倒好，是不是干脆把这表拆了，放在两个机子里面？那你怎么去ping端口？

其实，还是有解决方法的，因为在SSM框架，也就是spring的配置文件里面，配置多个数据源，一个数据源对应一个一个DB配置

而且放在两个机子里面，我觉得这种情况在实际中很正常。比如我这用户登录系统和学员系统是两家公司的，他们有一个合作关系，但是关系再好也不可能数据库放在一起，穿一条裤子啊！所以，就要有类似于中转机子一样的东西。

关于这一点，我在任务8的RMI实现中会去尝试，目前另外一个阿里云服务器暂时没有搞到手。

另外，关于阿里云的OSS图片服务，我也有一些思考，本次我的项目类似是用代理服务器的形式实现的，也就是客户端把文件字节码放在报文里面传给ESC服务器，然后我的ESC服务器再发给OSS服务器。当文件一大，这做无用功的流量就恐怖了，尤其是RMI实现后，这无用流量更多，效率更低。

所以我去看了下官方文档，他推荐是STS的方式：

我目前用的是这种：

但是我不会在前端搞这些东西，生成policy什么的，所以暂时无法实现，但是原理什么的大概清楚了，就是一个报文内容、地址的事情。

另外，说下springMVC上传文件的配置：

如果上传文件大于这个限定值，就会报错，为了优化用户体验，我在spring的异常处理器里面处理掉了：

最后OSS的工具类我是这样子写的：

明天计划的事情：遗留有一些BUG，明天去解决

遇到的问题：一些逻辑性错误，通过测试解决

收获：进一步思考了联表查询的意义