In my view, the biggest advantage of Spring is its big pool of services/interceptors. In all other respects, I like hivemind better, especially
- Most important to me: services have "service-models", dictating how they're instantiated and how their clients are tied to these instances. This makes it very easy to implement something like the "session per application-transaction" or even "session-per-user-transaction" pattern. Switching between these patterns is then just a matter of replacing the service-model attribute in the hivemodule.xml. - regarding hibernate patterns: session-per-user-session is good, if and only if, each user typically works with a well defined set of persistent objects and if most of the time each object is modified by only one user simultaneously. Most intranet/extranet apps I know fall in this category. Put differently: your hibernate Session should at any one time hold the objects that you anywayhold in the http-session/persistent-props and not *much* more. In a lot of apps, the user selects some "working set" of objects on some entry-screen and, subsequently navigates the result-list and the object-graph connected to it. So, for ne, a good point to clear the hibernate-session is when the user goes back to the entry-screen to choose a new working set. - It's small, clear & has few dependencies. - I like the way hivemind collects and merges its configuration from all hivemodule.xml's on the classpath. This makes it really easy to put config where it belongs without explicit include-statements. - I like Hivemind's emphasis of interfaces (you can have "raw-bean" services, but usually you have interface plus implementation class). regards, Marcus > -----Original Message----- > From: Dan Adams [mailto:[EMAIL PROTECTED] > Sent: Friday, September 30, 2005 11:27 PM > To: Tapestry users > Subject: hivemind vs. tapestry > > > Okay, I've read a bit online about this (like Howard's post) > and I don't > want to start a flame war or anything but I'm thinking about > design and > need to make a decision before this project goes much further. > > I'm currently using spring and hibernate and using services for all my > hibernate code. Unfortunately, i found out I was using the > session-per-operation antipattern (i know i know i'm sorry) > which led me > to think about how to implement session-per-request with detached > objects (or even session-per-user-session would be better i think if > thats really possible). So now I'm seriously wondering: is there an > advantage to using both spring and hivemind and if so what is it? Or > should I simply drop spring and using only hivemind services? > I'm using > spring beans for most everything right now. One thing to consider is > DI/IoC is the only thing I'm using spring for currently (i'm not using > the spring aop or transactions) so as far as my usage I'm not sure if > there is a big reason to stick with spring other than I like it. > > But can some of you out there with more experience with > tapestry/hivemind/spring/etc give me a little insight? Thanks. :) > > -- > Dan Adams > Software Engineer > Interactive Factory > > > --------------------------------------------------------------------- > 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]
