之前太长了，现在还是做mybatis。
首先我们要创建一个全局配置文件，这里面是对MyBatis 的核心行为的控制，比如mybatis-config.xml。
第二个就是我们的映射器文件，Mapper.xml，通常来说一张表对应一个，我们会在这个里面配置我们增删改查的SQL 语句，以及参数和返回的结果集的映射关系。
我们要执行对数据库的操作，必须创建一个会话，这个在MyBatis 里面就是SqlSession。SqlSession 又是工厂类根据全局配置文件创建的。
public void testMapper() throws IOException { String resource = "mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(resource); SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); SqlSession session = sqlSessionFactory.openSession(); try { BlogMapper mapper = session.getMapper(BlogMapper.class); Blog blog = mapper.selectBlogById(1); System.out.println(blog); } finally { session.close(); } } SqlSession session = sqlSessionFactory.openSession(); try { // 你的应用逻辑代码 } finally { session.close(); }映射器是一些由你创建的、绑定你映射的语句的接口。映射器接口的实例是从 SqlSession 中获得的。因此从技术层面讲，任何映射器实例的最大作用域是和请求它们的 SqlSession 相同的。尽管如此，映射器实例的最佳作用域是方法作用域。 也就是说，映射器实例应该在调用它们的方法中被请求，用过之后即可丢弃。 并不需要显式地关闭映射器实例，尽管在整个请求作用域保持映射器实例也不会有什么问题，但是你很快会发现，像 SqlSession 一样，在这个作用域上管理太多的资源的话会难于控制。 为了避免这种复杂性，最好把映射器放在方法作用域内。
SqlSession session = sqlSessionFactory.openSession(); try { BlogMapper mapper = session.getMapper(BlogMapper.class); // 你的应用逻辑代码 } finally { session.close(); }第一个是config 文件。大部分时候我们只需要很少的配置就可以让MyBatis 运行起来。其实MyBatis 里面提供的配置项非常多，我们没有配置的时候使用的是系统的默认值。
configuration 是整个配置文件的根标签，实际上也对应着MyBatis 里面最重要的配置类Configuration。它贯穿MyBatis 执行流程的每一个环节。这里面有很多的属性，跟其他的子标签也能对应上。
注意：MyBatis 全局配置文件顺序是固定的，否则启动的时候会报错。
第一个是properties 标签，用来配置参数信息，比如最常见的数据库连接信息。为了避免直接把参数写死在xml 配置文件中，我们可以把这些参数单独放在properties 文件中，用properties 标签引入进来，然后在xml 配置文件中用${}引用就可以了。可以用resource 引用应用里面的相对路径，也可以用url 指定本地服务器或者网络的绝对路径。
由于Java 类型和数据库的JDBC 类型不是一一对应的（比如String 与varchar），所以我们把Java 对象转换为数据库的值，和把数据库的值转换成Java 对象，需要经过一定的转换，这两个方向的转换就要用到TypeHandler。有的同学可能会有疑问，我没有做任何的配置，为什么实体类对象里面的一个String属性，可以保存成数据库里面的varchar 字段，或者保存成char 字段？这是因为MyBatis 已经内置了很多TypeHandler（在type 包下），它们全部全部注册在TypeHandlerRegistry 中，他们都继承了抽象类BaseTypeHandler，泛型就是要处理的Java 数据类型。
当我们做数据类型转换的时候，就会自动调用对应的TypeHandler 的方法。如果我们需要自定义一些类型转换规则，或者要在处理类型的时候做一些特殊的动作，就可以编写自己的TypeHandler，跟系统自定义的TypeHandler 一样，继承抽象类BaseTypeHandler<T>。
spring和springMvc：
1. spring是一个一站式的轻量级的java开发框架，核心是控制反转（IOC）和面向切面（AOP），针对于开发的WEB层(springMvc)、业务层(Ioc)、持久层(jdbcTemplate)等都提供了多种配置解决方案；
2. springMvc是spring基础之上的一个MVC框架，主要处理web开发的路径映射和视图渲染，属于spring框架中WEB层开发的一部分；
springMvc和springBoot：
1. springMvc属于一个企业WEB开发的MVC框架，涵盖面包括前端视图开发、文件配置、后台接口逻辑开发等，XML、config等配置相对比较繁琐复杂；
2. springBoot框架相对于springMvc框架来说，更专注于开发微服务后台接口，不开发前端视图，同时遵循默认优于配置，简化了插件配置流程，不需要配置xml，相对springmvc，大大简化了配置流程；
springBoot和springCloud：
1. spring boot使用了默认大于配置的理念，集成了快速开发的spring多个插件，同时自动过滤不需要配置的多余的插件，简化了项目的开发配置流程，一定程度上取消xml配置，是一套快速配置开发的脚手架，能快速开发单个微服务；
2. spring cloud大部分的功能插件都是基于springBoot去实现的，springCloud关注于全局的微服务整合和管理，将多个springBoot单体微服务进行整合以及管理； springCloud依赖于springBoot开发，而springBoot可以独立开发；
什么是面向切面编程呢？
如果给每个网页添加权限，就需要深入到各个页面的控制代码，来添加权限，
但是直接在url路由转移后直接一个控制函数不香吗，这样的做法，对原有代码毫无入侵性，这就是AOP的好处了，把和主业务无关的事情，放到代码外面去做。每次请求都有些重复的事情要做(日志记录，性能统计，安全控制，事务处理，异常处理)，这些都可以AOP。切入点也是xml实现的。
@Aspect 声明切面
@pointcut 切点
@before 声明建议
servlet(服务器端的应用小程序)必须在容器中，由容器启动和控制，才能用。
有了IOC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合，这样也方便测试，利于功能复用，更重要的使程序的整个体系结构变得非常灵活。在运行期，在外部容器动态的将依赖对象注入组件，当外部容器启动后，外部容器就会初始化。创建并管理bean对象，以及销毁他，这种应用本身不负责依赖对象的创建和维护，依赖对象的创建和维护是由外部容器负责的称为控制反转。
2.IOC（控制反转）和 DI（依赖注入）
IOC（Inversion of Control，控制反转）。这是spring的核心，贯穿始终。所谓IOC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。
DI（依赖注入）。IOC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的
BeanFactory实际上就是给类添加了许多属性默认值，就不用自己初始化默认值了，尤其属性很多且很没用的情况下，这很有用。
Application Context容器是BeanFactory子接口，也成为Spring 上下文，常用的才是这个，功能都是一样的，只是封装了而已。一个bean实际上是容器构造的类。
依赖注入也通过xml实现啊。其实就是上面的了。
SSM spring mvc spring mybatis
DIspatchServlet，url路由，都放在一个xml中。。。
@Controller会让类变成一个Handler，接着就是一个
@Request(url)，相当于Django的view吧。
一个类
@RequestMapping 在方法上面添加URL，用来处理参数吧
这是一个页面的MVC
最后返回的是一个jsp。。。
视图解析器，viewResolver，都是在xml上配置的。
整体如何运作的呢，就是从Controller开始(用于接受输入，返回输出，调用service)
然后就到了service(用来调用mapper，其实service提供不止数据库服务，甚至运算服务，等，这么理解)
然后就到了mapper，它在service里是自动填充的，为什么会自动填充呢？因为mapper是一个接口(interface)，它的实体其实是xml本身，相当于mapper实际上只是一个java语言的一个声明作用。用xml生成mapper的实例。
1. 接口正常书写，映射文件中SQL语句的占位符必须用 arg0 agr1…,或param1 param2…
接口：
public Customer getCustomerWithID(Integer id,String name); 1对应的配置文件中的SQL语句:
<select id="getCustomerWithID" resultType="com.itlike.domain.Customer"> <!-- select * from `customer` where cust_id=#{arg0} and cust_name=#{arg1} --> select * from `customer` where cust_id=#{param1} and cust_name=#{param2} </select>2.在接口中的形参前使用@param命名参数，映射文件中的SQL语句的占位符用@param命名的参数 注意，用@param命名后，SQL中的占位符不仅能用命名的名字，还能用param1 param2…但是不能用arg0 arg1… 接口：
public Customer getCustomerWithID(@Param("id") Integer id, @Param("name") String name); 1对应的配置文件中的SQL语句:
<select id="getCustomerWithID" resultType="com.itlike.domain.Customer"> select * from `customer` where cust_id=#{id} and cust_name=#{name} </select>
Apache是普通服务器，本身只支持html即普通网页。Apache只支持静态网页，但像php,cgi,jsp等动态网页就需要Tomcat来处理。由于Tomcat本身也内含了一个HTTP服务器，它也可以被视作一个单独的Web服务器。但是，不能将 Tomcat 和 Apache Web 服务器混淆，Apache Web Server 是一个用 C 语言实现的 HTTP web server；这两个 HTTP web server 不是捆绑在一起的。
Apache是web服务器，Tomcat是应用（java）服务器，它只是一个servlet容器，是Apache的扩展。 Apache和Tomcat都可以做为独立的web服务器来运行，但是Apache不能解释java程序（jsp,servlet）。
实际上，前端一个服务器，后端一个服务器，网页端，H5，小程序都用后端服务器，感觉更好啊。。。不仅可以重复使用，而且各个路由互相不受影响，尤其是前端vue路由与后端springboot路由。后端就用一个Tomcat，前面就直接使用apache，感觉超级好啊。
关于SpringBoot项目的创建，就更简单了直接maven创建或者去官网Spring Initializr下载demo.zip即可。 Controller实际上就是Django的view。
发现了，但是现在未授权。
{"code":401,"msg":"未授权"}怎么办？实际上是找到了，没找到就是404了。
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。
MVC中的M就是单纯的从网络获取回来的数据模型，V指的我们的视图界面，而C就是我们的ViewController。
在其中，ViewController负责View和Model之间调度，View发生交互事件会通过target-action或者delegate方式回调给ViewController，与此同时ViewController还要承担把Model通过KVO、Notification方式传来的数据传输给View用于展示的责任。随着业务越来越复杂，视图交互越复杂，导致Controller越来越臃肿，负重前行。脏活累活都它干了，到头来还一点不讨好。福报修多了的结果就是，不行了就重构你，重构不了就换掉你。
所以为了解决这个问题，MVVM就闪亮登场了。他把View和Contrller都放在了View层（相当于把Controller一部分逻辑抽离了出来），Model层依然是服务端返回的数据模型。而ViewModel充当了一个UI适配器的角色，也就是说View中每个UI元素都应该在ViewModel找到与之对应的属性。除此之外，从Controller抽离出来的与UI有关的逻辑都放在了ViewModel中，这样就减轻了Controller的负担。
view端改变后会自动改变model里的绑定数据，viewmodel里的数据变动后就直接修改view里的数据，这就是MVVM，vue的特点。
JQuery整个项目太大，单纯使用ajax却要引入整个JQuery非常的不合理（采取个性化打包的方案又不能享受CDN服务）
fetch: 是Jquery Ajax类似的，但是fetch纯js的，它提供了一个JavaScript接口，用于访问和操纵HTTP管道的部分，例如请求和相应，全局用fetch()方法做处理。
axios： axios是在Vue2.0后推荐使用的，Axios 是一个基于 promise 的 HTTP 库，可以用在浏览器和 node.js 中。
接下来就是前后台数据对接如何对接上的问题。axios，这也是现在流行，浏览器支持最好的方式。
跨域问题的出现是因为浏览器的同源策略问题，所谓同源:就是两个页面具有相同的协议（protocol），主机（host）和端口号（port），它是浏览器最核心也是最基本的功能，如果没有同源策略我们的浏览器将会十分的不安全，随时都可能受到攻击。
当我们请求一个接口的时候，出现如：Access-Control-Allow-Origin 字眼的时候说明请求跨域了
在vue中使用proxy进行跨域的原理是：将域名发送给本地的服务器（启动vue项目的服务,loclahost:8080），再由本地的服务器去请求真正的服务器。
本地的服务器？
Access denied for user 'root'@'localhost' (using password: YES) 老是遇到这句话 密码要用引号括起来阿
还是不对。。。 The server time zone value '�й���ʱ��' is unrecognized or represents more than one time zone. 修改时区。。。。天啊 还是有问题。。。 应该还是bean的问题，这回看别的教程吧。 看别的教程也没有bean 报错内容：com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class com.entity.User and no properties discovered to create BeanSerializer 解决方法：将实体类的属性，访问权限由 private 修改为 public 即可！！！ 或者自己设置setter和getter
现在归纳一下后端吧。
大概一个页面一个controller，一个数据库一个service，entity，map三件套，就是这样。
一个字算两个字节吧，1kb就1024字节，大概500个字，1MB就是50，0000，五十万字，20KB吧，大概存一万个字。
那现在做完了？是的。
现在部署到服务器上，就是
nohup java -jar xxx.jar
直接开通port，就可在后台一直挂载运行了。。。。。。 会出现一个端口号，这个端口号就是项目运行的端口号！
ps -ef | grep java 查看java 运行的几个端口号
kill -9 22899 杀死端口号，关闭程序。
网站上传图片的话，就是有特定的文件类@file，这种，只要存入特定位置就好了。
