Can I apply IOC in this scenario?

[yangsun]

Hi,

I am a new comer here. And I am programming a mid-sized program. Currently, I feel a little bit uncomfortable for the archetecture. Most uncomfortable comes from the transfer of an object everywhere in the program. I have a little background of IOC. So I am wondering whether we can apply IOC in our program to make things better. The scenario is as below:

We want to build a portal program to provide the service to others (one of the goal is the insurance application). We want to make part of the common functionality reusable. So one decision point is to separate the program to two parts, one is the portal (using jsf), and the other is the reusable utility (such as connection pool, caching and etc). The utility classes use a lot of static methods since they don't need to maintain the internal state. And the utility class will be used in other scenarios. So we don't want it know something related to the portal, such as session and request.

The problem comes from the token. The token comes from the SSO (single sign on) feature. That token is used to identify a user's identification. Since the SSO is outside of the web server, so its lifetime is not controlled by the web sever. In order to align the lifecycle of token with the session, we put it to a object (for example, UserConfigInfo). That object is per-session based. When the session is created, the object will be created explicitly by portal side, and then if the session is timeout, the object will be automatically gabage collected.

The problem comes. Since the utility classes does not maintain the state, so the utility class will ask the caller from portal side to transfer a UserConfigInfo object for every call. So basically, every method in utility classes has that parameter. And the only usage of the object is to get the token. I think it is a problem that every method signatures are polluted by a UserConfigInfo object.

I think the problem comes because we do not have a mechnism to make a session wide singleton object. And from my knowledge of IOC, I think IOC can bring that feature. But I don't know whether it is a good scenario for applying IOC and how to apply it effectively.

Could anyone share some insights with me?

Thanks.

[belugabob]

Yangsun,

Version 2.0 of Spring introduces the concept of 'scopes' to beans.

Check out the reference docs for details...

http://static.springframework.org/sp...factory-scopes

I have a use for this mechanism myself, but it's not at the top of my job list right now, so I'm afraid I can't provide any examples - look at this thread for some sample code from Rick Evans (I will do something with your samples soon, Rick - I promise)

http://forum.springframework.org/showthread.php?t=26920

Regards,

Bob

[Costin Leau]

If you the methods already contain a UserConfigInfo, does the code uses the object or not?
IoC applies very well to injecting dependencies (inside an object) while your case is about getting the dependency on the chain call.
An action plan would be to identify the concern that cross your application domain - such as the UserConfigInfo - and move them through AOP into one place (if you're a beginner I would suggest to implement them as methodInterceptors through Spring Proxy-based AOP).
I think once you'll remove the cross-cutting concern you'll see that you application is much clearer and you can start removing the utility classes and replace them with IoC - i.e. the container maintains the object lifecycle and injects them into various components.

Note however, that in both cases you'll have to do refactoring of the existing code - I would suggest to get a slice of your application and springify it. This might seems a bit complicated but it's quite easy and it offers you the freedom to experiment in pace without destroying the entire project.