【without Spring】【J2EE Development without Spring】

                                                                                           


首先对spring的某些优点我是表示认同的
spring的优点有很多，比如spring有很多有用的类库，就算你不打算引入spring框架（我是指那堆配置文件），也同样可以使用用它的类库。比如spring的思想是很好的,控制反转，依赖注入。

然而在spring的框架下，很多东西被顶礼膜拜式的使用了，由于使用者对spring已经顶礼膜拜，
所以难以发现其中的不足，反而对其不足津津乐道

我下面例举spring xml配置文件的几个缺点

1 Spring自己制造依赖，然后再自己解决依赖

Spring是在哪儿做到没有依赖，制造依赖的呢？

做为一个java开发者,各种 ide(jbuilder,eclipse)本来已经提供了足够好的功能，让你解决编写代码时会产生的各种语法错误，比如在你写错要调用的类名的时候，IDE是不会让你编译通过的，而会即时提醒你类名写错了，这是JAVA语言本身提供的特性，当你觉得这个类名，方法名，包名最初起的不够好，而你想要重构的时候，ide可以做到整个项目范围内的类名或方法名等全部改变。IDE能做到这一些，也是依赖JAVA语言本身的特性

然而当你引入spring配置文件之后，这些功能完失效了，改完之后，项目启动不起来了。

因为ide不了解spring的配置文件也需要重构，也需要重命名，
但是spring崇拜者说了，spring有eclispe插件，装上这个插件之后就可以重构了。
可是我本不需要插件啊，可是我用的是jbuilder2006呢,可是装插件了解插件的过程还需要时间啊。
这就是spring制造的字符串依赖，产生的重构困难，spring发现后，自己又造插件去解决问题，而不是告诉大家别依赖配置文件了，配置文件本就是代码嘛....（自己制造问题，再解决问题）


2 Spring让开发者不关心模块的初始化顺序和关闭顺序
  spring下的bean是被spring容器初始化的，初始化顺序不能明确定义，你不知道什么是先new的，什么是先set过的
  你不知道那个模块先启动那个模块后启动.当然，你可以用spring的deponed-on属性去限定，但是在配置文件越来越多的时候，你还有什么更好的方法去全局的掌握deponed-on呢。
  程序的关闭也是一个比较大的问题 ，即使你有本事决定那个模块先启动，你也没能力控制那个模块先关闭，
  但是程序的关闭毕竟也是需要顺序的，你不能说数据访问模块都关闭了，另外一个线程还在调用数据访问模块给数据库添加数据吧。


3 spring让运行代码如此之长,但配置文件必须是运行时的一部分时，配置文件就是代码

<beans>
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName">
<value>net.sourceforge.jtds.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:jtds:sqlserver://127.0.0.1:1433/Sample</value>
</property>
<property name="username">
<value>test</value>
</property>
<property name="password">
<value>changeit</value>
</property>
</bean>

多难看的配置文件啊？难道它可以运行中还可以配置吗？难道因为它和编译器无关，就不是代码的一部分了吗?
代码原本可以如此简单

BasicDataSource datasource=new BasicDataSource();
datasource.setDriverClassName("net.sourceforge.jtds.jdbc.Driver");
datasource.setUrl("jdbc:jtds:sqlserver://127.0.0.1:1433/Sample");
datasource.setUsername("test");
datasource.setPassword("changeit");

当然有些东西还是要放到配置文件里的，上面的数据源就应该放在配置文件里，这样在部署时就方便了
但是Spring确把所有东西都放到了配置文件里

4 AOP 调试之累
  当错误发生的时候,我相信大家更愿意看到的是，异常从哪儿抛出的,程序调用是从哪儿开始的，从哪儿结束的，事务是从哪儿提交的，从哪儿回滚的，到底是哪儿出了问题，然而AOP把这一切打乱了，我们强烈的依赖到这个上面，找不到开始，找不到结束。开发时的时间和调试测试的时间一样重要


什么是没有Spring配置文件的依赖注入思想
由于spring文件有这么多问题，所以就不要用它。
自己写一些容器类，代替Spring的 ApplicationContext，
这个类里面初始化原本在你想spring配置文件里的东西,可以公开的东西就public
如果模块过多，也可以分成多个类来写初始化,在自己的初始化类里设置类与类的关系,你的位置就是要站的和ApplicationContext站的一样高,只要你觉得ApplicationContext的存在合理,
程序中的其他地方对ApplicationContext的依赖合理，那么你自己的容器类就是同样合理的

将Spring 配置文件扔掉,在程序中尽量减少字符串依赖！
SURE!!!  Why not?



原贴地址：http://www.riabbs.com/as.jsp?asmc=showtopic&bid=230&topicid=6

很多人批评spring，但通常理由很勉强，很多根本不成立！

Spring team的技术水平是无庸致疑的。

很多人都烦spring的配置文件，但是个人觉得通过Spring 2.5 的annotation，完全可以打造出一个最小化的最核心的与业务无关的架构级配置文件，这个交给项目组里的一个架构师去维护，一般情况下可以做到开发人员无须接触到配置文件；

    难道楼主想回到J2EE With EJB的时代，EJB本身的那一套复杂的规范只会让人觉得更加头疼。但是Spring的确也存在其不是很方便的地方，但是这些现象也普遍存在于当下流行的Java开源框架之中，比如Struts、Hibernate等，哪个不是到了后来一堆的配置文件，照成了楼主所说的字符串依赖，重构起来很麻烦，要修改代码，还要去找相关的XML配置文件进行修改。
    个人觉得，Java框架应该多吸取一下Rails框架的长处，采用COC的思想，那样的话才是广大J2EE开发者真正的春天。

做为一个java开发者,各种 ide(jbuilder,eclipse)本来已经提供了足够好的功能，让你解决编写代码时会产生的各种语法错误，比如在你写错要调用的类名的时候， IDE是不会让你编译通过的，而会即时提醒你类名写错了，比如当你觉得这个类名，方法名，包名最初起的不够好，而你想要重构的时候，ide可以做到整个项目范围内的类名或方法名等全部改变。

然而当你引入spring配置文件之后，这些功能完失效了，改完之后，项目启动不起来了。
=============================================================================

Intellij Idea可以在重构类时自动修改“任何”xml配置文件

Eclipse also

写代码还要依赖IDE，按照你的说法，那也是没事儿找事儿，世界没有依赖？才怪！
在我看来，纯粹就是nonsense，跟spring好像没有多少关系，抓点儿皮毛就来当令箭...

对于没有深刻理解J2EE开发过程的人而言，随意评论一个框架是非常没有道德的。

这篇文章很多地方是比较想当然的，批评一个东西很容易，如同可以说正方形不圆，圆形没棱角。
评价一个技术，关键要看你站在什么角度去评价，要有具体的应用环境，而不是空谈。
比如你可以批评汽车为什么开不到天上，大家会觉得你的批评没有道理，因为其设计目的不包含这个功能。
spring当初的设计目标就是去除代码中的依赖，转移到配置文件中来。
这篇文章表现出对这种设计方式的质疑，这个角度来说是很好的，我欣赏其质疑精神，单仅凭自己的感觉而完全否定配置文件的做用，显得武断。
我曾经个人给人做过一个应用系统，就拿数据库配置来说，因为是给另外的人进行配置，我不在现场，所以这个软件必须要求我把数据库配置以配置文件方式给出，如果你用代码配置，特别是java代码，难道我还要给部署的人介绍javac或者eclipse?在java的发展历史上，配置文件的出现是一个很大的进步，拿spring来说，类之间的依赖在几个配置文件之中完全体现，在一个基于spring开发的系统中，只要浏览spring配置文件，整个系统的架构就会被很快理解，反之，我读过的很多不依赖配置的libray源码则是需要花费相当时间。spring也有java config,可是我更本没兴趣去实践。当前很多人反对使用配置文件的背景在于配置文件被滥用，而不是配置文件这条路走错了，所以出现了annotation。我一直认为annotation和配置文件是互补关系，就拿annotation的依赖注入来说，我认为这个有利于写这个类的程序员，却不利于查看整个模块的程序员。
不废话了，如果只站在程序员个人完成工作的角度，或许直接上代码效率最高，但是软件考虑的远不止这些，团队，部署等等，都会左右技术的选择。我对这篇文章不感冒的，就在于其角度太过狭隘，而通过狭隘的角度来否定一个流行的技术，无异于华众取宠耳。