SpringMVC+Mybatis开发框架学习笔记

发表于 | 更新于 | 字数统计3.6k字 | 阅读时长12分钟 | 分类于

Spring, SpringMVC, Struts和Mybatis联系与区别

Spring

  1. Spring是一个轻量级的控制反转IOC和面向切面AOP的容器框架，它有许多优点:
    • 降低了组件之间的耦合性 ，实现了软件各层之间的解耦
    • 容器提供单例模式支持,以及事务管理，消息服务等众多服务
    • 容器提供了AOP面向切面编程，利用它很容易实现如权限拦截，运行期监控等功能
    • spring对于主流的应用框架提供了集成支持，如hibernate，Struts等，高度开放
    • spring的DI机制降低了业务对象替换的复杂性
  2. 控制反转是指由Spring负责控制对象的生命周期(例如创建和销毁)以及对象之间的关系，它是通过依赖注入来动态地给某个对象提供它所需要的其他对象，依赖注入其实是通过反射实现；具体的讲：当某个对象需要另外一个对象协助的时候，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在Spring中创建被调用者的工作不再由调用者来完成，而是由spring来完成，然后注入调用者。这个就叫做控制反转，依赖注入
  3. 面向切面编程AOP是对面向对象编程（OOP）的补充，OOP将程序分解成各个层次的对象，而面向切面编程从程序运行角度考虑程序的结构,将程序运行过程分解成各个切面，并提取业务处理过程的切面;它是一种对应用执行过程中的步骤的动态抽象，可以获得各个步骤之间低耦合性的隔离效果；Spring中的AOP还提供了声明式事务管理
  4. 依赖注入的三种方式
    • 接口注入（interface injection） 接口注入指的就是在接口中定义要注入的信息，并通过接口完成注入。
    • Set注入（setterinjection）Set注入指的就是在接受注入的类中定义一个Set方法，并在参数中定义需要注入的元素。
    • 构造注入（constructor injection）构造注入指的就是在接受注入的类中定义一个构造方法，并在参数中定义需要注入的元素
  5. Bean的作用域

SpringMVC和Struts—-表现层框架(MVC)

  • Spring MVC框架是一个MVC框架，通过实现Model-View-Controller模式来很好地将数据、业务与展现进行分离。Spring MVC的设计是围绕DispatcherServlet展开的,DispatcherServlet负责将请求派发到特定的页面控制器; 通过可配置的handler mappings、view resolution、locale以及theme resolution来处理请求并且转到对应的视图;

  • Struts2是一个基于MVC设计模式的Web应用框架，它本质上相当于一个servlet，在MVC设计模式中，Struts2作为控制器(Controller)来建立模型与视图的数据交互.

  • 区别

  1. Struts2是类级别的拦截， 一个类对应一个request上下文，SpringMVC是方法级别的拦截，一个方法对应一个request上下文

  2. 拦截器实现机制上，Struts2有以自己的interceptor机制，SpringMVC用的是独立的AOP方式，这样导致Struts2的配置文件量还是比SpringMVC大。

  3. SpringMVC的入口是servlet，而Struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。

  4. SpringMVC验证支持JSR303，处理起来相对更加灵活方便，而Struts2验证比较繁琐

  5. 设计思想上，Struts2更加符合OOP的编程思想， SpringMVC就比较谨慎，在servlet上扩展。

  6. spring MVC和Spring是无缝的，SpringMVC开发效率和性能高于Struts2

Mybatis

  1. Mybatis是一个支持普通SQL查询，存储过程和高级映射的优秀持久层框架。MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装；MyBatis可以使用简单的XML或注解用于配置映射，将接口和Java的POJO（Plain Old Java Objects，普通的Java对象）映射成数据库中的记录

Spring常见用法

Spring AOP实现原理

  1. Spring AOP使用了两种代理机制，一种是基于JDK的动态代理，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；另一种是基于CGLib(动态字节码增强技术)的动态代理，通过CGLib可以为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类方法的调用，并在拦截方法相应地织入横切逻辑；之所以需要两种代理机制，很大程度上是因为JDK本身只提供基于接口的代理，不支持类的代理。尽管实现技术不一样，但都是基于代理模式，都是生成一个代理对象。
  2. 两种代理的具体实现方法
    • JDK动态代理：主要使用到 InvocationHandler 接口和 Proxy.newProxyInstance() 方法。JDK动态代理要求被代理实现一个接口，只有接口中的方法才能够被代理。其方法是将被代理对象注入到一个中间对象，而中间对象实现InvocationHandler接口，在实现该接口时，可以在 被代理对象调用它的方法时，在调用的前后插入一些代码。而 Proxy.newProxyInstance() 能够利用中间对象来生产代理对象。插入的代码就是切面代码。所以使用JDK动态代理可以实现AOP
    • CGLIB（code generate libary）:字节码生成技术实现AOP，其实就是继承被代理对象，然后Override需要被代理的方法，在覆盖该方法时，自然是可以插入我们自己的代码的。因为需要Override被代理对象的方法，所以自然CGLIB技术实现AOP时，就必须要求需要被代理的方法不能是final方法，因为final方法不能被子类覆盖。
  3. 使用场景和效率对比:JDK动态代理所创建的代理对象，在JDK 1.3下，性能强差人意。虽然在高版本的JDK中，动态代理对象的性能得到了很大的提高，但是有研究表明，CGLib所创建的动态代理对象的性能依旧比JDK的所创建的代理对象的性能高不少（大概10倍）。而CGLib在创建代理对象时性能却比JDK动态代理慢很多（大概8倍），所以对于singleton的代理对象或者具有实例池的代理，因为不需要频繁创建代理对象，所以比较适合用CGLib动态代理技术，反之适合用JDK动态代理技术。此外，由于CGLib采用生成子类的技术创建代理对象，所以不能对目标类中的final方法进行代理。
  4. ‘’‘’‘’配置了这句话的话就会强制使用cglib代理。 默认就是false。

Spring常用注解

  1. @Service用于标注业务层组件
  2. @Controller用于标注控制层组件（如struts中的action）
  3. @Repository用于标注数据访问组件，即DAO组件
  4. @Component泛指组件，当组件不好归类的时候，我们可以使用这个注解进行标注
  5. @PathVariable当使用@RequestMapping URI template 样式映射时， 即 someUrl/{paramId}, 这时的paramId可通过 @Pathvariable注解绑定它传过来的值到方法的参数上
  6. @Autowired和@Resource都可以用来装配bean，都可以写在字段上，或者方法上,用于完成装配的工作,消除 set ，get方法; @Autowired属于Spring2.5的；@Resource为JSR-250标准的注释，属于J2EE的;
    • @Autowired默认按类型装配，默认情况下必须要求依赖对象必须存在，如果要允许null值，可以设置它的required属性为false，例如：@Autowired(required=false) ，如果我们想使用名称装配可以结合@Qualifier注解进行使用
    • @Resource，默认安装名称进行装配，名称可以通过name属性进行指定，如果没有指定name属性，当注解写在字段上时，默认取字段名进行安装名称查找，如果注解写在setter方法上默认取属性名进行装配。当找不到与名称匹配的bean时才按照类型进行装配。但是需要注意的是，如果name属性一旦指定，就只会按照名称进行装配
  7. @RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径
  8. —- 自动去扫描base-pack下面或者子包下面的java文件，如果扫描到有@Component @Controller@Service等这些注解的类，则把这些类注册为bean；Use-dafault-filters=”false”的情况下：指定的不扫描,指定的扫描

Servlet

  1. Servlet是一个按照Servlet规范编写的一个Java程序，此程序是基于Http协议的，运行在服务器端(如tomcat)，主要是处理客户端的请求并将其结果发送到客户端。

  2. Servlet怎么处理一个请求

    • 当用户发送一个请求到某个Servlet的时候，Servlet容器会创建一个ServletRequst和ServletResponse对象。
    • 在ServletRequst对象中封装了用户的请求信息，然后Servlet容器把ServletRequst和ServletResponse对象传给用户所请求的Servlet，调用Servlet的service方法。service方法从ServletRequest对象获得客户请求信息，处理该请求，并通过ServletResponse对象向客户返回响应信息。

  3. Servlet生命周期分为三个阶段

    • 初始化阶段 —- 调用init()方法
    • 响应客户请求阶段　—-　调用service()方法
    • 终止阶段　—-　调用destroy()方法

cookie和session

  1. 会话跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
  2. Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。cookie的内容主要包括：名字，值，过期时间，路径和域名
  3. 客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

  4. cookie 和session 的区别：

    • cookie数据存放在客户的浏览器上，session数据放在服务器上。
    • cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
    • session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用COOKIE。
    • 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存一定数目个cookie。
    • 将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中

  5. html5提供新的存储 sessionStorage用于本地存储一个会话（session）中的数据，这些数据只有在同一个会话中的页面才能访问并且当会话结束后数据也随之销毁。因此sessionStorage不是一种持久化的本地存储，仅仅是会话级别的存储。localStorage用于持久化的本地存储，除非主动删除数据，否则数据是永远不会过期的

ngix和apache, tomcat的区别

  1. apache和nginx都属于静态页面服务器，tomcat属于Java Servlet容器，用来生成动态页面的;Apache只是作为一个转发，对JSP的处理是由Tomcat来处理的。
  2. Apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程,nginx处理静态文件好,耗费内存少，支持高并发比较好，配置简单，也更适合做代理服务器
  3. nginx处理请求是异步非阻塞的epoll模型，而apache则是阻塞型的select模型

高并发Web网站处理方案

  1. 主-从方式进行数据库同步复制，将查询和其他操作分别在不同的服务器上进行操作，例如M-M-Slaves方式，2个主Mysql，多个Slaves;Slaves可以进一步负载均衡，将select操作适当的平衡到不同的slaves上
  2. 表分区, 对数据库表从业务层面上进行分区。例如根据一定的切分方式，比如把id切分到不同的数据库集群去

  3. HTML静态化, 尽可能使网站上的页面采用静态页面来实现,例如

    • HTML静态化之前:当一个Servlet资源请求到达WEB服务器之后我们会填充指定的JSP页面来响应请求: HTTP请求—-Web服务器—-Servlet—业务逻辑处理—访问数据—填充JSP—响应请求
    • HTML静态化之后: HTTP请求—-Web服务器—-Servlet—HTML—响应请求

  4. 缓存机制

  5. 图片服务器分离：对于Web 服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他 们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用 服务器和图片服务器上，可以进行不同的配置优化
  6. 数据库集群和库表散列
  7. 大型网站架构