floater
Java Jedi
总版主
发贴: 3233
积分: 421
|
于 2005-12-07 11:40
yea, I've notice it too at javaeye. here are my personal opinions(which mean they are entirely arguable): 1. spring xml originated from a configuration tool, then has been growing into almost the entire J2EE spectrum. It grows from practices. We've got to have these to magnify the IoC effects. Plus, it solves one of the key problems in practice - config dependencies that we are not supposed to know. So taking out this solution and others(e.g., datatype conversion and ability to add new datatype conversions) would significantly weaken the infrastructure of applications. 2. IoC is a concept, as well as an implementation. It works at the class and component level. Adding IoC to the method level is having too much details, namely programming in xml without compile time checking, this is too much. Similarly, unit testing in xml has the same reason that shouldn't be there. Remember, we don't want to do coding in xml. 3. Component architecture in Spring is sufficient in practice, the worries that nuts has are unwarrantied in my experience. Nuts worries that beans could step on each other's toes. The chance of that is none in practice, though possible in theory. This is because components are seperate, each components have their own config xml, and thus there is no overlap, unless they are doing the same thing. The other case is the parent/child context, where the overlap is intentional because they are used in ejb/web containers and in different classloaders. But this case is not composition intentionally.
Most of the "new features" added here are mostly unused in practice, and thus this comparison doesn't have much significance in practice.
But this is a good practice, it does have some good ideas, like using ant's tag structure. However, we should have a better understanding on the entire logic in the bigger picture with all the details. This is why I think Rod's first book is the best, it explains details in a large scale.
my 2cents.
"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
|