I've been putting off a design decision for a few weeks now, but it is time to make a choice. Our application uses Spring, Hibernate and Struts and is organized somewhere between PoEAA Domain Model/Service Layer and Fowler's dreaded Anemic Domain Model (which I do not consider all bad, btw). We have stateless Manager classes that mirror business use cases and from the outside are exposed as services (in one app).
Many of our Manager classes do things (or tell domain objects to do things) that require auditing, filtering or some other "current user" concern. In order to avoid passing the user on 75% of the method calls, I would typically require the user in the Manager's constructor, or pass it to a factory method so that every call has access to the calling user. But with Spring, we can't do that, and besides that introduces state to those Managers.
So we have two solutions (or three if you break it down):
1. Make managers stateful (not application/business state though, this is an important distinction)
a - Instantiate a new copy every request
b - Hold a reference in user session
2. Pass the current user on just about every method call to the business logic
I'm leaning towards 1a. I don't like 1b becuase every fiber of my being says don't stuff unnecessary crap into user session. I don't like 2 because it pollutes the method signatures and opens the API up to misuse.
1. Am I missing a possible solution here?
2. Do you reckon 1a is the way to go?
3. What do you suppose the performance tradeoff between 1a and 1b are? CPU hit to instantiate lots of objects vs. memory hit to retain many long-lived copies?
Thanks in advance. I couldn't find anything concrete in this forum, the Spring manual or PetClinic. If I missed a section, please point me in the right direction.