floater
Java Jedi
总版主
发贴: 3233
积分: 421
|
于 2004-08-27 23:10
Sigh, I just don't have time to comment these posts, but I guess I just have to do this. code is one thing, the reason behind it is another, the concept underneath it is a third. We need a little bit comprehension.
Spring真正的精华是它的Ioc模式实现的BeanFactory和AOP,它自己在这个基础上延伸的功能有些画蛇添足。 The core package(bean factories) and aop are foundations for others(context, dao, orm, transactions, web, etc). These others are not 画蛇添足, they solve particular problems, most stated in the expert 1-1 book. I guess this 板桥里人 doesn't understand what those problems are and thus have these comments.
其实说白了,大家"惊奇"的是它的IoC模式(使用AOP功能需要了解AOP,比较难),那么,Spring之类的Ioc模式是什么? 就是:你在编制程序时,只要写被调用者的接口代码,具体子类实例可通过配置实现。
Ioc模式是什么知道的人不多,但是,当他知道生成对象不用再使用new了,只要在配置文件里配置一下,他感到新鲜,其实这就是Ioc模式的实现,PicoContainer是另外一种真正轻量的Ioc模式实现,PicoContainer还是采取代码将对象注射一个小容器中,而Spring采取配置文件。
Yes, this is the behavior. The real reason is the code dependency. Every line of code we write introduces dependency. This dependency creates all sorts of trouble and inconvenience for us and thus we want to isolate them desperately. When you have millions of lines of code and hundreds of applications, this is a very serious problem. Other benefits are reusable code, uniform resource handling, easy testing, flexibility, etc.
配置式编码其实有利有弊,编码本来可通过开发工具或编译器检查错误,但是过分依赖配置时,就会经常出现因为粗心导致的小错误,如果调试程序出错经常是因为配置文件中小写字母写成大写字母,不知道你是怎么心情?
This is undeniably true, so we need a tool for compile time rather than runtime. I consider this a minor side effect of the surgery. Every solution to any problem will have some side effect. If it's a minor, we can live with it, then it's a good solution. I consider Struts' side effect as major.
Spring最近还发表了Spring without EJB的书,这倒是说了实话,Spring和EJB其实是相竞争
This 板桥里人 indeed doesn't understand what the problems are. Spring is not trying to replace EJB, it only replace it where it's broken, although EJB is broken in a lot of areas. Still that old saying, if it's not broken, don't fix it. The books have this, read them - when you need distribution(imposed by the business requirements, not others, like developers want to use it). So it's a compliment, and it's a very nice one because we don't need to pay for something we don't need.
如同黑与白,如果硬是将两者搭配使用,显得不协调
Spring simplifies EJB programming a little bit, to the extent it can handle. Without Spring, if you have to use EJB, that's fine. With Spring, it helps a lot, e.g., the factory bean from spring, etc. It's your choice. But I would go with Spring. If you write 10 EJB beans, you would realize there are some common code in these beans and callers. Spring just puts these common code into libs and so makes your lives easier.
可伸缩性和重/轻量,谁是实用系统的架构主选?
It's up to requirements, we just want to do minimal work.
1. Spring不介入EJB容器
I said it in 黑与白's comment. Another benefit the hookups between EJB and other components, integration. This is more on the EJB client side.
The rest of the comments about transactions are due to historic reasons and compatibility. EJB's transactions are heavyweight. If you don't need distribution, you should use Spring's transactions, it's simpler and easy to test. However, if you have some code already in production, you can use Spring in conjunction with EJB, that's why there is 还要套上EJB. Actually, I think the nested transaction is a new feature in 1.1, required by some users, as I read bbs.
如果硬套上EJB使用,只是相借助其集群分布式功能,而这个正是Spring目前所缺少的
This is precisely that Spring didn't plan to do. If EJB can do the job in the distribution, why bother to reinvent the wheel? Let EJB do the job, and use Spring to hook EJB with others.
为了避免你每次使用Spring时想到粘糊糊的异型,不如Spring without EJB,这也正是Spring的初衷
rod johnson clearly said in the book and on the bbs that use it when it's appropriate, when you need distribution. I don't know wherethis guy got this idea.
也是它的一个畅销书名
I don't even know this is a popular book or not, do I need to care, hell no. As long as it's useful for me. Harry pot and lord of the ring are more popular, I have them setting on my harddrive for a long time and never touched them.
We need experience and background to understand the logic behind the superfacial behaviors. The logic deduction solely based on the behaviors could be off the right track, if we don't understand what the problems we are facing. Rod's two books are the most comprehensive to state these problems, as far as I know. Get the logic right first, and then see how they do it, not the other way around(unless we are at the code level).
floater edited on 2004-08-27 23:15
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Refactoring - Improving the Design of Existing Code
|