|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-30
stamen 写道 3)Spring使你更加方便地使用常用企业功能，如JavaMail，Timer，远程调用，缓存，安全等，Spring使得利用这些类库得到了很大的简化，而如果你直接用这些类库，学习曲线陡峭得很多； Unknow---- says: 第三点是有价值了 有些人如果不被大象甚至恐龙折磨上十年八年的话，是绝对不会意识到马有多么的好驱策，多么的灵活 如果选择，他会说：马不错呀 吃的少 ... ... |
| 返回顶楼 | |
|
发表时间：2006-10-30
引用 有些人如果不被大象甚至恐龙折磨上十年八年的话，是绝对不会意识到马有多么的好驱策，多么的灵活 如果选择，他会说：马不错呀 吃的少 这个比较经典  虽然才刚开始学spring，但是还是真正感受到了它的精彩，继续学习中 |
| 返回顶楼 | |
|
发表时间：2006-10-30
quaff 写道 ajoo 写道 偶是觉得spring的xml配置语法即使在2.0后仍然是很繁琐的。
spring的功能强大，继承了大量的第三方系统，还有acegi这类的私生子，这没得话说。理论上这是一个事实标准的胜利，是占据了先机的胜利，而不是技术上的胜利。 另外spring的灵活性也还有些疑问。 我们最近需要refactor一个遗留系统。该系统自己用property file定制了对象创建，并且在代码里面硬编码了“缺省实现类”。总而言之，是个long story。 在考虑重构这个系统的时候，没有发现spring提供温和的渐进改革方法。要用spring，似乎就不能再用现在这个property file了，也就是说，要一下子把所有用这个遗留框架的代码彻底改掉。 还有，spring也缺乏给容器外面创建的对象注射依赖的能力。 这些都是一些很细节的缺陷了。 最后说一点。凡是说用了spring就获得了ioc的好处的人，根本就没懂ioc。IoC，或者说Dependency Injection，根本不依赖于你是否用一个IoC容器。new MyBusinessObject(new SomeService())这就是一个IoC了。 1.spring的xml配置虽然繁琐了一些,但通过看xml的配置基本上就知道了整个系统的结构,对象与对象之间的关系,我基本上不用auto-wire.大家还是把spring的xml配置仅仅看作是配置,其实它也是编程,特别是spring2.0使用schema配置,还点更加明显. 2.你可以在一个ApplicationContextAware的bean里面实例化你property file里面的bean,然后注册到ApplicationContext,对外面对象的注射依赖请看 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory类里面的autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck) 1。xml还是做配置最合适。一旦用作编程，往往就非常蹩脚了。我倒是还比较愿意用autowire的。如果一概manual wire，那么还要spring干啥？groovy好不好？ spring 2的schema说实话我不太理解rod为什么要引入schema这么复杂的东西。自定义tag就得要schema？ant得自定义task也不需要schema。 2。我主要是不太希望java代码依赖这个properties文件。理想情况是xml config文件里面指向这个properties文件，java代码直接读xml config文件。 3。外面对象的注射么。autowireBeanProperties还算可用吧。要是它能允许选择要注射的property名字会更实用一点。 另外，容器内没有登记的类能做contructor注射么？类似： autowireConstructor(AClassNotRegisteredInContainer.class) 还有，对这样一个场景： 容器内很多service组件的创建需要注射appId, sessionId两个变量。 appId, sessionId这两个变量会随着程序运行的上下文不同而不同。（比如，两个线程使用两个不同的sessionId） 怎么做？莫非每个线程都要先登记appId, sessionId？还要锁定整个容器？ |
| 返回顶楼 | |
|
发表时间：2006-10-30
只看了开头,
但是连单元测试,敏捷开发的好处都怀疑的人,你跟他讲Spring,那不是对牛谈琴吗? |
| 返回顶楼 | |
|
发表时间：2006-10-30
人，技术人员，尤其是J2EE相关的技术人员，很需要主动的怀疑甚至否定自己，并且在外界和自己的观点之间寻找个好的平衡点。
技术人员很聪明，所以很自信，所以很喜欢钻牛角尖。 想说服别人，真难。 |
| 返回顶楼 | |
|
发表时间：2006-10-30
总算看到一个相同想法的人unknown
|
| 返回顶楼 | |
|
发表时间：2006-10-30
robbin说得很好，我觉得就应该那样说如果我遇到这样的人
|
| 返回顶楼 | |
|
发表时间：2006-10-30
ajoo 写道 quaff 写道 ajoo 写道 偶是觉得spring的xml配置语法即使在2.0后仍然是很繁琐的。
spring的功能强大，继承了大量的第三方系统，还有acegi这类的私生子，这没得话说。理论上这是一个事实标准的胜利，是占据了先机的胜利，而不是技术上的胜利。 另外spring的灵活性也还有些疑问。 我们最近需要refactor一个遗留系统。该系统自己用property file定制了对象创建，并且在代码里面硬编码了“缺省实现类”。总而言之，是个long story。 在考虑重构这个系统的时候，没有发现spring提供温和的渐进改革方法。要用spring，似乎就不能再用现在这个property file了，也就是说，要一下子把所有用这个遗留框架的代 码彻底改掉。 还有，spring也缺乏给容器外面创建的对象注射依赖的能力。 这些都是一些很细节的缺陷了。 最后说一点。凡是说用了spring就获得了ioc的好处的人，根本就没懂ioc。IoC，或者说Dependency Injection，根本不依赖于你是否用一个IoC容器。new MyBusinessObject(new SomeService())这就是一个IoC了。 1.spring的xml配置虽然繁琐了一些,但通过看xml的配置基本上就知道了整个系统的结构,对象与对象之间的关系,我基本上不用auto-wire.大家还是把spring的xml配置仅仅看作是 配置,其实它也是编程,特别是spring2.0使用schema配置,还点更加明显. 2.你可以在一个ApplicationContextAware的bean里面实例化你property file里面的bean,然后注册到ApplicationContext,对外面对象的注射依赖请看 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory类里面的autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck) 1。xml还是做配置最合适。一旦用作编程，往往就非常蹩脚了。我倒是还比较愿意用autowire的。如果一概manual wire，那么还要spring干啥？groovy好不好？ spring 2的schema说实话我不太理解rod为什么要引入schema这么复杂的东西。自定义tag就得要schema？ant得自定义task也不需要schema。 2。我主要是不太希望java代码依赖这个properties文件。理想情况是xml config文件里面指向这个properties文件，java代码直接读xml config文件。 3。外面对象的注射么。autowireBeanProperties还算可用吧。要是它能允许选择要注射的property名字会更实用一点。 另外，容器内没有登记的类能做contructor注射么？类似： autowireConstructor(AClassNotRegisteredInContainer.class) 还有，对这样一个场景： 容器内很多service组件的创建需要注射appId, sessionId两个变量。 appId, sessionId这两个变量会随着程序运行的上下文不同而不同。（比如，两个线程使用两个不同的sessionId） 怎么做？莫非每个线程都要先登记appId, sessionId？还要锁定整个容器？ 1.这是见仁见智的问题,你用autowire是为了节约配置代码,我不用autowire是为了看清楚bean之间的依赖关系,各有优缺点,反正spring都支持怎么选择还是靠开发者自己,即使是必 须manual wire我也会选择spring也不选groovy 如果acegi的配置全部配成autowire,那要弄清楚acegi的机制只有一个一个找java源文件去看 spring 2.0引入schema只是途径不是目的,这个东西反正是面向框架开发者的,开发复杂丢给框架开发者去搞,一般的spring用户没必要去管它,只要用它来简化配置就可以了 我觉得acegi很适合做成自定义tag的配置 2.总之你得写代码去解析这个properties文件,不是用java代码难道用ruby?你的java代码不依赖这个properties文件是不可能的,可能你希望spring已经写好这样的代码,你稍微配 置一下就可以用,但是你想想spring怎么可能知道你的properties的结构和意义?spring不是神,不要希望什么事情它已经给你做好了 3.你要这样的功能你自己去写一个这样的实现就行了,做好了提交给spring team.spring本来就推荐用属性去注入而不是用构造参数去注入 autowireConstructor(AClassNotRegisteredInContainer.class),这个我不知道你的yan能不能做到这么智能化,如果你的类有多个构造方法,spring怎么知道你要调用的那个构造方 法. |
| 返回顶楼 | |
|
发表时间：2006-10-30
竟然看完了。你朋友很多基本的spring和acegi的概念都没有搞清。真是不明白为什么可以对自己不了解的东西妄下断言呢？
|
| 返回顶楼 | |
|
发表时间：2006-10-30
dada 写道 竟然看完了。你朋友很多基本的spring和acegi的概念都没有搞清。真是不明白为什么可以对自己不了解的东西妄下断言呢？
何谓很多基本的spring和acegi的概念？spring,acegi只是为你做了N多的事情，留给你的只是一定量的配置，若干的代码量而已。有什么新东西吗？甚至可以说和ajax的产生没什么区别，唯一的好处就是其体现出来的设计思想，可有一些也是借鉴而已。 不是所有的项目都“体大如牛”的，从实用角度考虑，什么方便用什么，现在可用的东西那么多，需要什么我拿来用就是了，只要能简单，正确地表达出我某一个交易要做什么，不能做什么，与其他交易或其他系统中的业务是否发生关联，如何通讯就可以了。 重构只是一个美好的愿望，全中国有那么多的业务系统，大多数都是一个版本一个版本迭代出来的产物，你觉得上一个版本有bad smell，代码冗余，耦合极强，难道你就去重新构造这个业务系统？等你重新构造后，它的市场价值也没了，投产还有何意义？你所做的一切还有何意义？所以我觉得重构对提高个人代码素养有很大的好处，对实际的业务系统意义不大。 再来说说XP，所谓的“结对编程”，国外不晓得乍应用的，对于国内，乍应用，一个开发，一个辅助，两人轮换，可对于开发，每人都有自己的一套小九九，对于不同的需求，每人都有不同的理解，估计要两人能达到一致，恐怕就得耗费一段时间了，在开发过程中也难免不会出现意见的分歧，这样情况如何解决？老外是怎样解决的？也许你会说，每人做一个交易，一个流程，这样就不“打架”了，貌似可行，可前提是这两人得“对眼”，要么能力接近，要么关系不错，否则如何解决两人的合作关系？除非是一男一女合作。。。。。。 随便说说，欢迎讨论。。。。。另外回贴的时候，不知为何cpu占用过高，风扇时不时地在转，我用的maxthon，没开其它东西，噢，对了，开空调来的：）怀疑是文本编辑器有资源占用问题，呵呵。 |
| 返回顶楼 | |
