spring概念

在这里插入图片描述


纵览Spring , 读者会发现Spring 可以做非常多的事情。 但归根结底, 支撑Spring的仅仅是少许的基本理念, 所有的理念都可以追溯到Spring最根本的使命上: 简化Java开发。
Spring的目标是致力于全方位的简化Java开发。 这势必引出更多的解释, Spring是如何简化Java开发的?为了降低Java开发的复杂性, Spring采取了以下4种关键策略:基于POJO的轻量级和最小侵入性编程;通过依赖注入和面向接口实现松耦合;基于切面和惯例进行声明式编程;通过切面和模板减少样板式代码。几乎Spring所做的任何事情都可以追溯到上述的一条或多条策略。我将通过具体的案例进一步阐述这些理念, 以此来证明Spring是如何完美兑现它的承诺的, 也就是简化Java开发。 让我们先从基于POJO的最小侵入性编程开始。激发POJO的潜能如果你从事Java编程有一段时间了, 那么你或许会发现(可能你也实际使用过) 很多框架通过强迫应用继承它们的类或实现它们的接口从而导致应用与框架绑死。这种侵入式的编程方式在早期版本的Struts以及无数其他的Java规范和框架中都能看到。Spring竭力避免因自身的API而弄乱你的应用代码。 Spring不会强迫你实现Spring规范的接口或继承Spring规范的类, 相反, 在基于Spring构建的应用中, 它的类通常没有任何痕迹表明你使用了Spring。 最坏的场景是, 一个类或许会使用Spring注解, 但它依旧是POJO。举个例子, 请参考下面的HelloWorldBean类:1234567package com.chi.spring;public class HelloWorldBean {  public String sayHello() {    return "Hello World";  }}可以看到, 这是一个简单普通的Java类——POJO。 没有任何地方表明它是一个Spring组件。 Spring的非侵入编程模型意味着这个类在Spring应用和非Spring应用中都可以发挥同样的作用。Spring的非入侵式就是不强制类要实现Spring的任何接口或类,没有任何地方表明它是一个Spring组件。 意味着这个类在Spring应用和非Spring应用中都可以发挥同样的作用。尽管形式看起来很简单, 但POJO一样可以具有魔力。 Spring赋予POJO魔力的方式之一就是通过DI来装配它们。 让我们看看DI是如何帮助应用对象彼此之间保持松散耦合的。依赖注入任何一个有实际意义的应用(肯定比Hello World示例更复杂) 都会由两个或者更多的类组成, 这些类相互之间进行协作来完成特定的业务逻辑。 按照传统的做法, 每个对象负责管理与自己相互协作的对象(即它所依赖的对象) 的引用, 这将会导致高度耦合和难以测试的代码。举个例子, 考虑下程序清单1.2所展现的Knight类123456789101112131415package sia.knights;public class DamselRescuingKnight implements Knight {  private RescueDamselQuest quest;  public DamselRescuingKnight() {    this.quest = new RescueDamselQuest();  }  public void embarkOnQuest() {    quest.embark();  }}DamselRescuingKnight只能执行RescueDamselQuest探险任务。可以看到, DamselRescuingKnight在它的构造函数中自行创建了Rescue DamselQuest。 这使得DamselRescuingKnight紧密地和RescueDamselQuest耦合到了一起, 因此极大地限制了这个骑士执行探险的能力。 如果一个少女需要救援, 这个骑士能够召之即来。 但是如果一条恶龙需要杀掉, 那么这个骑士就爱莫能助了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值