I don't want to get into a whole "thing" about it because it doesn't matter to me overly much in the long run but did want to make at least a couple points. ;) (inlined of course)
On 11/21/06, Sam Gendler <[EMAIL PROTECTED]> wrote: <snipped>
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.
I can think of a few ways to compare them offhand: -) Spring bean id's / name / and bean aliases are all very uncomfortable naming schemes for me. It would be like having to manually create all of the unique client id's that Tapestry gives you in an html page by hand. Bleh . Hivemind has true namespace support, which means I can easily/cleanly segment off my various services using "foo.bar.name" type familiar conventions without having to worry about ID conflicts blowing up on me. -) Hivemind has thread support / Factory Support / Pipeline support / Chain of Command and probably others. All incredibly useful programming concepts captured and available "for free". -) Hivemind lazily initializes everything "by default". -) Hivemind allows me to create shared configuration points that anyone can contribute to...Whether directly within my source code or when using my hivemind library within their own. Those are a few off the top of my head. Not the kind of thing that makes people swoon but definitely the kind of thing that makes me happy when writing services.
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.
This is true. Hivemind doesn't try to wrap every possible concrete service type available. To unabashedly steal a phrase I heard once - Spring is a framework for building applications, Hivemind is a framework for building frameworks. To be fair though, I've done much more "enterprise" development than I have web and happened to have implemented the following Hivemind services not too long ago very easily without using a single library from Spring: -) Quartz -) Drools -) JMS / ActiveMQ -) Hibernate -) Rmi transport -) Integrated Tapestry/Hibernate transaction management. -) Standalone appserver bootstrapping Maybe there are others, probably I'm forgetting everything by now. I can say that it's all been done in an extremely large enterprise system that is deployed nationwide in critical care areas of hospitals. The system also interfaces (transparently thanks to hivemind) with so many different sources of data that I know I wouldn't be able to remember them all if I tried. It's definitely nearing 100's at a minimum.
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.
As for xml being easy to manage vs hard coded static strings or some other unjarring form of non configurable option I can't argue with that statement. I can say that there's not a single thing you can do in Xml that I can't do with annotations. (except write more xml ) Annotations have the added benefit of carrying behavior with them. Meaning that you can apply them in unexpected places and get the same results. Transaction demarcation is nice, but really - wouldn't it be nice to just be able to say @Transaction(<however you want to say PROPOGATION_REQUIRED>) on a listener method and be done with it? Doesn't mean you can't call services and have them participate in the same transaction. Just means that you are putting the boundary where it belongs. All without the author of the annotation having to know how and where you might possibly apply it. <snipped>
--sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
