Hm, couldn't resist to drop a few remarks on that (inline): > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Sam Gendler > Sent: Wednesday, November 22, 2006 2:24 AM > To: Tapestry users > Subject: Re: Re: Tapernate Access multiple database > > Actually, Spring does so many things that hivemind doesn't > (at least as far as I am aware), that you can't even compare
Spring does support stateful services? session-per-conversation? As far as I know, it doesn't even have service-models. > 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 thats a bit of an odd comparison. If you can use a Tapernate/Honeyomb-like approach out-of-the box you need exactly ZERO lines of code per service method since it's just ta-per-request or per-conversation by default. Rollbacks on Exception, and the like is included, of course. If you can't use it out-of-the-box, because you really need multiple ta-resources, the alternative is not coding ta's manually, but doing some not really complex changes to make tapernate/honeycomb handle these. > 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'd suspect, that most of that code is replaced by your container's ta-manager, right? Spring, on it's own, does not do a lot in terms of ta-coordination apart of letting you use it, when it's around. > > 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 You don't need interfaces, bean-services are there since HiveMind 1.1.1 (at least) > 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. That's true to exactly the same extent for HiveMind-based solutions, of course. > > 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. Ironically, Tapernate IS just a convenient wrapper around the Spring Hibernate/TA-management stuff ... That's about the only reason I, personally don't use it (until James comes up with his conversation support, at least). Additionally, If I need to use multiple db's, I really like to map the foreign ones into the first one via updatable remote views / materialised views. That gives you the extra benefit of releasing the tight coupling, that usually goes with db-integration-patterns. And you get rid of costly two phase-commit protocols on the app-server level. And you can tune your performance by doing the db-coupling asynchronously (materialized views versus plain ones). Marcus > > --sam > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
