来源:linux宝库作者:linux宝库 发布时间:2007-09-30 00:00:00


在这里,Spring指的是Spring研发框架,一种依赖注入容器的实现。首先,我声明我没有一点冒犯Rod的意思(您是个优秀的人)。但是坦白地说,我不能狂热的追随您的研发框架。更为严重的是,我注意到,我所考虑的这些可能对于Spring框架的使用率来说是危险的,并且有可能降低对Spring框架的使用率。我读到一个关于Spring的很重要的文章或书籍,看起来似乎除了我,任何的人都喜欢Spring。但是我有什么损失吗?可能采用Spring是J2EE一个类似“膝跳反射”的事情(这种事情能够不经过大脑)。“J2EE不是好东东,Spring的人说他们的产品更好一些,所以Spring一定是好的”但是事情并不是那样的。
第二点,我仅仅讨论Spring,而不讨论依赖注入。我喜欢依赖注入,并且每天都使用他。他是个摆脱service locators的好方法。 我记不得有多少次有研发者对我说,“我的上一个项目使用了Spring,这个框架真好”。但是没有人能清楚明白的说出他们究竟喜欢Spring的哪一点,Spring到底帮助了他什么。所以我敢说,他们喜欢setter注入,这使得他们的代码更加灵活和可测;但并不一定必需Spring。我猜有些人并没有完全理解依赖注入,所以他们依赖Spring来帮助(或强迫?)他们使用依赖注入。然而,这种好处并没有在量上大于Spring在您的代码上带来的负面影响,这些负面相应在下面的清单上。 Spring的狂热者公开的指责J2EE,但是从他们的指责中,我能够说,Spring实际上既不是轻量级也不简单。Javadocs未必是必要的,但是这一切都要怪罪于一个用户API吗?最起码J2EE清楚的将API和他们的实现分离开来。Spring的鼓吹者吹捧Spring不会“动”您的代码,例如,您不必去实现任何的Spring指定的接口(生命周期接口除外等等)。新闻特写,“XML配置文档是我们自己的代码,通过他,我们能组织起很多的代码,这些代码都是Spring给定的” 为什么我一定要把我任何的依赖使用XML文档来表达?我是需要把我任何的对象都用Spring来处理,还是仅仅一些没有考虑成熟的?上面我所说的这些问题,Spring文档没有给出一些可靠的答案,而且任何的Spring书籍也没有给出。我假定我们使用Spring是为了产生任何的对象。那么这样还是我们喜欢的Java编程吗?我希望在编译期和随后的装载期能够确定这些对象,而不是在运行我的代码的时候才能够确定。Spring能做到支持这些吗? 很明显,我希望装载一些像JDBC驱动这样的动态实现的依赖(即不需要编译期的检测);但是在我的系统中,这样的依赖只是一小部分;而剩下的部分,我们代码的绝大部分却不是。我是在使用一种强类型的语言。假如我希望像Spring那样,我会使用Ruby。难道Spring的配置文档不像是我们在猜测着将Java代码写入XML文档里吗?难道那些使用Spring的研发者使用起Java来不那么舒服?我确信增加了一个XML层并不能使得代码变得哪怕是一点点简单。 现在回过头来谈谈关于对Spring API的依赖的问题。我不得不调用容器来产生我的第一个对象(假定剩下的Spring管理对象是注入的),不是吗?我需要一些方法在编译期间来测试我所请求的对象是正确的类型;我不想靠抛出违例的方法。究竟,我真的需要一个容器吗?在Spring里,您通过使用一个唯一的ID来获取对象。我假定大部多数的研发者在他们Java代码里使用一个String类型的常量来定义他们的ID。Spring并不能帮助我使得我的Java代码里的ID值和我的XML文档里的ID值保持一致。当一个对象已够用了的时候,为什么要使用两个对象?是否我们真的把任何的信息组织到一起放到了容器里?是Java的包和类不够用了吗? 更有一个困扰我的问题是,在我的XML配置文档里,我不得不引用Spring实现的类,我不想管这些东西。在Spring的计划里,我听说更加简单的、域范围的XML将在2.0版本中被使用,但是我到现在还没有看到。为什么这些不能早一点被采用呢? 什么继承上的东西啊?关于超常类名置换的变换。但这些都不是我的风格。 Spring在哪里支持了JDK1.5的泛型?我知道您有很多客户运行在JDK1.4甚至JDK1.3的版本上,但是这和JDK1.5没有分歧啊。泛型打开了通向像这种框架的各种各样的可能性的大门。这些是我最喜欢的JDK1.5的新特性,拥抱这些新特性吧! 您曾看过每次您产生一个对象Spring要做多少事情吗?我需要在运行期内有少量的instanceof,而大多数是在装载期的 Class.isAssignableFrom()。不是因为内部的实现给最终用户带来了很多的麻烦,而是因为把他作为了一个测试框架剩下部分质量的试金石。一个好的对于bean的创建渠道的重构将会很容易的被遵循和产生更加高质量的代码,并且无需求助于更多的继承就能被重用。
Auto-wiring也有同样的问题。每一个人真的在使用他吗?或是为未来的重要功能的一个铺垫? Spring是怎么处理领域范围的 ?我听说在2.0版本中,Spring最终会支持HTTP request和session的。我很惊讶难道现在这些没有被支持吗,那么Spring的用户在整个期间里都做了些什么。难道是新的版本将使我能够定义自己的领域范围?例如,他将实现我想要一个“conversation”领域范围,就像Seam将要支持的那样。
我们将不涉及MVC或AOP框架。幸运或不幸的是在某一时候,我将不使用一个依赖注入容器。难道不认为PicoContainer已远离了简单二字。他也和Spring有同样的问题,我认为Aslak和Jon已转移到了Ruby的领地。更有其他的研发框架没有这样的问题吗? 幸运地,简单的采用依赖注入设计模式能让您完成Spring的90%的工作,特别是当您在并不急于使用他的时候。这是我推荐的方法。我的确没有看到让我自己马上使用Spring的理由。没有他我工作的很好。假如您在使用他,那么请您把眼睛睁大一些,使用怀疑的、鉴赏的目光。假如仅仅因为某人有流行的开源框架,他们有很好的市场,并且他们被一些大的公司支持(IBM在很多年前就推荐我使用Struts)。但这并不意味着他们知道什么工具对您最好,尽管他们比您知道什么是更好的。
|
还没有关于此文章的相关评论!