• Spring到底是个什么东西?


    虽然看了一阵子书,可以依然感觉Spring非常抽象。

    Spring的介绍:

    引出

    依赖注入。 方式有: 构造器 注入。(+面向接口)实现松耦合。

    创建应用组件(对象)之间协作的行为 称为装配。 即 注入 叫做装配。

    常见的是通过XML 配置文件。

    AOP

    struts2的拦截器是用来过滤页面请求,页面请求到达action前会被过滤器拦截,
    而AOP实际是GOF设计模式的延续,设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,主要是用来解决OOP和过程方法不能够很好解决的横切(crosscut)问题。

    http://blog.csdn.net/shendl/article/details/526362

    横切关注点的两种实现方法
    软件系统,可看作由一组关注点组成。其中,直接的业务关注点,是直切关注点。而   直切关注点 提供服务的,就是横切关注点
    有两种方法可以提供横切关注点,一种是传统的OOP方法,提供一个与直切关注点的实现一样的类来提供服务。另一种是最新的AOP方法,提供一个Aspect方面(Spring AOP中叫advisor顾问)来提供服务。
    OOP方式是:业务类使用对象引用,使用“委派”的方式,调用横切类的方法(服务)。
    这是“主叫”式的服务。业务类用显示代码来呼叫服务。这在业务类中增加了与“直切关注点”概念无关的代码,破坏了封装性,增加了业务类和服务之间的耦合
    AOP方式是:提供一个Aspect方面,这个方面的概念类似于“类”,它封装了“横切关注点”的实现代码。并且还提供了“切入点”。切入点是“连接点”的集合。切入点就是定义了Aspect方面为哪些类的哪些方法提供服务。(其实,就是把需要服务的对象,集成到了服务端,而不是业务端的主叫的方式。)
    AOP的实现方式有很多种。最早的方式是编译时织入。AspectJ就是使用这种方式。AspectJ的特殊编译器将业务类和Aspect方面的代码组装在一起,从而实现服务的无缝接入。这种方式,源代码中的业务方法和Aspect方面无关。
    另一种很典型、很精巧的实现方式是使用动态代理模拟实现AOP。这是现在最流行的方式。JBoss AOP框架和Spring AOP框架都使用这种方式。
    这里我介绍一下Spring AOP框架提供横切关注点服务的方式。编写一个方面,这个方面也是一个一般的pojo类,但是它需要提供一个接口。
    然后,使用Advisor顾问(就是方面,是方面+切入点)进行配置,配置接口和切入点模式。在程序运行到连接点方法时,构建一个动态代理类,返回一个谧名的java类,而不是直接使用业务类。这个谧名类组装了业务类和Advise建议(就是方面,SpringAOP的术语)。
    由此可见,AOP实现横切关注点的方式要比OOP方式好得多。
    而在AOP实现中,我更欣赏Spring AOP 这样运用动态代理模式实现的AOP。这种方式不需要任何辅助工具即可开发AOP。
    但是,对于开发AOP也要注意一点:  Spring AOP的advice代码只能够在连接点方法之前、之后调用,或者在异常被抛出之后调用。
    这样,就要求我们的目标方法(就是连接点,Advice要捆在它上面)必须够小,要把一个大方法分割成多个小方法。这就需要“重构”技术来帮忙。当然,这不是什么缺点,反而是一个让你养成好习惯的机会。“面向方法重构!”
    AOP这种技术的提出是一个了不起的成就。这个技术的始作俑者AspectJ本身的实现技术十分笨拙。
    AOP思想实际上是一个软件设计思想的发展,“横切关注点”的发现,使施乐的科学家们创造了AOP这样一种“面向方面(横切关注点)编程”的思想。也使他们生造出了笨拙的怪胎AspectJ。而另一些也在苦苦思索OOP面临问题的一线程序高手,立刻从AOP思想中获得久久寻找中的解决之道。
    他们从设计模式中翻出了“动态代理模式”和“装修者模式”,用她们优雅的实现了JBossAOP,SpringAOP这样的pojo型的AOP解决方案!

    继续Spring介绍:

    Spring是一个 基于容器 的框架。如果没有 配置Spring,那么它就是个 空容器,毫无用处。

    因为,Spring目的是简单化 java编程,

    它是通过 Spring容器来实现简单化的,各种配置,反正不是在java代码中,硬编码。

    Spring3也可以基于注解:

    http://club.1688.com/article/22918141.html

    Spring理解:

    由于类的封装的特性,与逻辑无关的代码是不应该封装进来的。每个类都是如此。

    由此,带来的问题是,每个类都是设计成,与其他类的耦合性不那么高,那么,这些类之间如何进行协作呢??

    如果照此设计,那么无法协作。

    Spring填补了这个空白,它把所有类,粘和到了一起。

    也就是说,类的独立性,要求了它不能包含过多耦合性的代码,每个类都是如此,这样就带来了问题:谁来让类之间耦合到一起呢?答案就是Spring。

    若,不使用Spring,就只能把耦合相关代码,添加到类里面,这样不利于复用,也不易测试。

    使用了Spring的好处,就明白了。

  • 相关阅读:
    冒泡排序
    线程同步
    线程取消
    线程分离
    第3月第2天 find symbolicatecrash 生产者-消费者 ice 引用计数
    第3月第1天 GCDAsyncSocket dispatch_source_set_event_handler runloop
    第2月第25天 BlocksKit
    第2月第24天 coretext 行高
    第2月第6天 iOS 运行时添加属性和方法
    第2月第5天 arc invocation getReturnValue
  • 原文地址:https://www.cnblogs.com/dayInAndOut/p/3910370.html
Copyright © 2020-2023  润新知