Craig McClanahan schrieb:
Actually, I'd be surprised (and impressed) if Spring 2.0 did
something different. The basic philosophy of all the IoC
frameworks I've looked at is that they only need to do their magic
once, when the bean is initially created. Whatever happens after
that is the responsibility of the application.
And, that being said, tell me again why your Spring-created beans
cannot be Serializable? That seems to be an architectural design flaw
for an application that needs to be supported by a
multi-server-instance application server, where the session might get
migrated back and forth.
Regards,
Ingo
Craig
Well as I understood the spring 2.0 reference it should be possible to
inject a request scoped bean into a session scoped bean, so spring must
call back, so you get each time a fresh request-scoped bean. But I'm not
really sure about this.
Back to my application design.
I'm using AndroMDA to generate my business and data access layer; the
presentation layer I'm still writing manually.
My controller beans (jsf backing beans) are thin beans just to trigger
my service beans (spring beans) from the business layer.
So a typical structure of my objects looks like this:
RegistrationController ------> RegistrationService -------> UserDao
-------> HibernateDaoSupport
Sometimes I need to save some data like "Did the user accept the user
agreement during the registration process". I added this temporal values
to my RegistrationController, because it is his decision whether all
needed data is collected to trigger the business layer or not. But this
results in that my controller is in the session scope.
So as I mentioned before, maybe I am wrong here. Maybe it is really
smarter to separate the controller objects from state data and put them
into application or request scope.
What do you thing about this?
Regards
Ingo
