就是把spring抽出来之后系统还是可以跑 的,这就叫非入侵性,系统不依赖于spring;

解决方案 »

  1.   

    呵呵,说的最简单一点, 就是你自己写的类里面不引用spring的包,和spring的api无关。
      

  2.   

    “采取了很多用XML配置值的方法。”
    这个应该无关,spring这个文件只能是spring自己用,别的框架用比较吃力。实际上是和你自己的良好设计有关的。如果你的系统是面向接口来写的,那么维护起来就很方便了。你自己也可以实现一个相应的框架啊,或者是采用同类产品pico来实现同样的功能。
      

  3.   

    其实spring的无侵入性只是某种程度上的,并不是完全无侵入
      

  4.   

    "其实spring的无侵入性只是某种程度上的,并不是完全无侵入"同意,这个说法!
    比如,要使用spring的事务管理,那么就需要使用Spring的事务代理类,
    而且 spring对jdbc的异常做了封装,实际还是需要侵入的。spring  的侵入程度相对来说,是比较低的!
      

  5.   

    实际上一般Spring所倡导的无侵入性一般来说都是指它的IOC框架,象楼上所说的事务管理,或者诸如AOP等,都是有侵入的,如果设计的好的话,可以把损失降低到更小,但的确不是一点侵入都没有。例如你使了它的AOP,你会发现以后要改的时候,也是很麻烦的一件事。
      

  6.   

    我感觉IOC是代码的非侵入性程度比较高,几乎都是靠配置来解决
    AOP也是靠配置,但非侵入性程度稍微低点当然每个人的看法不一样其实你原来用spring开发的产品改为其他的估计也不是一件很容易的事
    不过其他结构的改为spring的到是相对简单点
      

  7.   

    感觉Spring的开发模式很多就是靠配置搭配起来的。真不知道这种是增加了开发难度还是降低了开发难度。个人觉得你只要在你的Project中植入了IOC和AOP,不管是好是坏,那一定会对项目造成影响。就是一种“入侵”
      

  8.   

    如果是只用IOC的话,我觉得用PICO等,只要做很少的配置,是可以集成过去的,只不过相当与把spring的配置文件翻译成pico的就行了,譬如一个properties文件,何况spring本身也支持properties文件类型。IOC影响不是很大,但是如果AOP的话,如果你用的地方很多,就比较麻烦了,凡是AOP的地方全部都需要改写,工作量就会很大了。靠配置搭建不是错误,至少给了你一个可以自己选择,或者是分析这个配置的机会,真正的硬编码才是让你感到头痛的。就好比一个系统一样,如果让你定制的程度很大,你自己发挥的余地就比较大,如果什么都写死了,你只能固定用系统给你的功能,你绝对哪一个更好呢?
      

  9.   

    虽然AOP工作量比较大,但都是与业务逻辑相关性不大的,比如日志,事务等.....也就是说配置好后,日后修改的机会也不大。在看到gigix的一篇文章(http://gigix.blogdriver.com/gigix/93784.html),当中有一段是这样的:衡量一个IoC容器最重要的因素还是“侵入性”——也可以理解为组件对容器的依赖程度。Spring(http://www.springframework.org)和Pico(http://www.picocontainer.org)虽然一直争吵不休,都认为自己对组件的侵入性是最低的,但实际情况是两者都几乎是完全无侵入:只要是通过setter或者constructor插入的对象属性,都可以用Spring或者Pico来执行依赖注入。实际上,单就IoC容器而言,Spring和Pico是完全可互换的,它们对组件没有任何额外的要求——毕竟你总要用setter和constructor来设置属性,不是吗?