On 11/21/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
I guess that depends on what you consider having to "write code" . All that xml is nice but seems to really have just moved the code to a new format that doesn't require re-compilation. I can't argue that spring isn't nice though, I just think hivemind is light years ahead of it. It's too bad that it's still in the stone ages when it comes to comparing them with documentation.
Actually, Spring does so many things that hivemind doesn't (at least as far as I am aware), that you can't even compare them. As for getting transactionality without writing code, I'd say there's no comparison between the single line of 'code' I have to add to an XML file in order to wrap a method in transaction semantics (including handling of rollbacks, using existing transaction or starting a new one) and having to manually add code to do the same thing on every service method, especially since I can use wildcards in the XML file to handle multiple methods in the same manner. The fact that I can swap in and out JTA transactions, hibernate transactions, and JDBC transactions, again with only a single modification to an XML file, is a godsend as a project grows over the course of its use. When we went from one database to 2, and then 3, we didn't have to do anything but modify a config file to use J2EE transactions instead of the built in hibernate ones. There is just no comparison between the complexity of the application context file and the code it replaces. As far as I am aware, hivemind does a great job with dependancy injection, but doesn't offer the vast majority of other functionality available from spring - transaction management, quartz integration, aop integration, messaging, etc. I suppose I could use hivemind IOC to instantiate all the spring framework classes that provide the functionality I just listed, but that just seems like an obtuse solution, especially when it isn't clear (to me, at least) that the baseline IOC/dependancy injection code itself is particularly superior. They both accomplish the same tasks, and spring doesn't absolutely require an interface which is important when using libraries you don't control). Hivemind also has a much smaller community of users which is significant when building a sizeable engineering team. And really, even if it was just moving code into a config file that doesn't require recompilation, there are distinct advantages in having just that when architecting a project with 500,000+ lines of code and a team of 20 engineers. It means that I, as an architect, can manage transaction semantics for our entire suite of applications from a single location, rather than relying on 20 engineers who are 11 time zones and 6,000 miles away to get it right, or having to code review all those extra lines of code. Instead, my engineers worry about making sure the service method does what it claims it will, and I make sure that it participates in any necessary transaction correctly from the app context. Incidentally, I disagree that a single database is the minority case. That is true when talking about building an external facing website, but not at all true when building enterprise solutions. That's the whole reason the j2ee framework exists. A sizeable company may well have tens of databases that need to be integrated into internal applications, and pulling reports from a data warehouse isn't just common, it has been a requirement on nearly every project I've worked on in an enterprise context. Hell, in my current company, I've got data being fed to me from 4 different sources (salesforce.com, domain db, data warehouse, another 3rd party service), although I combine two into a single db. It is, however, probably the minority case for tapestry users, so I'm not saying tapernate went in the wrong direction on that point. Most apps complex enough to want multiple dbs probably aren't going to be looking at something like tapernate, anyway. I want more control than it offers me. Chicken or egg, I suppose. --sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
