Migrating Existing App to Spring Rich Client

[oliverhutchison]

Ollie (and Keith if you're monitoring this topic), do you think it's okay, short term, if I use Application.services().getApplicationContext() sparingly in my legacy code until I refactor it to use dependency injection?

My advice - do it if it makes sense. What are the beans that you need to access? If they're not Spring Rich related I'd be putting them into a different app context and access them through that.

During migrating you're never going to have an ideal setup as you need to juggle the needs/interfaces to 2 possibly quite different frameworks. I've found that by creating a set of classes that adapt Spring Rich to my old framework a lot of the pain has been reduced as I can continue to use my existing windows/page/editor management system but I get to use Spring Rich for forms and control creation. This also keeps risk at a manageable level as you can then chip away at the migration piecemeal.

So I could modify my existing in-house views to contain Spring Rich forms?

Why not? The Spring Rich form interface is so simple it shouldn't be to hard to adapt it, but, I've not seen you old framework ;-)

Ollie
[/code]

[oliverhutchison]

Stefano,

The app's not huge but as I'm the only person maintaining it's big enough for me not to not want to attempt a complete overall. In fact, as it's fully functional, from a business point of view, I couldn't really justify spending the time converting it anyway.

Ollie

[cyboc]

What are the beans that you need to access?

Our legacy code has a number of MVC triads, arranged hierarchically (i.e HMVC - see this topic for more details on HMVC). Each MVC triad can be instantiated multiple times. For example, let's say we have a triad for entering a new customer. Well, what often happens is our users will be part way through entering a new customer when they get a phone call that causes them to simultaneously start entering another new customer. In this case, we would need two instances of that triad.

The model classes in these triads currently access a business facade via JNDI -- in other words, pretty standard, ugly J2EE orthodox architecture...yuck. We also use a few singletons here and there to do miscellaneous lookups and to resolve some dependencies -- again, yuck. We're slowly refactoring this mess to use Spring Framework's various features, especially dependency injection and the nice support for various peristence implementations. We've also decided that we really don't need the complexity of three tier so we are converting to a standalone app.

Refactoring the persistence layer is actually fairly easy so far. Refactoring the app to use dependency injection is not so easy so far. We have a lot of cases where ClassA instantiates his collaborator ClassB, who instantiates his collaborator ClassC, etc. And as mentioned above, we also use singletons in some collaborations. It would be nice to have the container instantiate the classes and wire the collaborations through dependency injection.

As for Application.services().getApplicationContext(), I thought that for now, we could use it to do things like allow a model instance to lookup it's business layer facade. Of course, I would like the container to do this for me through dependency injection but it would require quite a bit of refactoring. We want to take baby steps right now.

I was also thinking that we could use Application.services().getApplicationContext() to get resources like messages, images, icons, etc.

If they're not Spring Rich related I'd be putting them into a different app context and access them through that.

I assume you mean beans that are Spring Framework related (as opposed to Spring Rich Client related) like DAOs, business layer facades, datasources, etc? If so, I guess you're recommending putting Spring Rich Client beans in one context and Spring Framework beans in another context (like in Petclinic where there are separate "richclient-application-context.xml" and "business-layer-context.xml" files)?

Now where I'm somewhat confused is, to minimize initial refactoring effort with my current achitecture, should I be loading both xml files into the same ApplicationContext (like what Petclinic does in PetClinicStandalone.java)? Or should I load them into separate ApplicationContexts? Your quote above seems to indicate separate ApplicationContext instances.

During migrating you're never going to have an ideal setup as you need to juggle the needs/interfaces to 2 possibly quite different frameworks. I've found that by creating a set of classes that adapt Spring Rich to my old framework a lot of the pain has been reduced as I can continue to use my existing windows/page/editor management system but I get to use Spring Rich for forms and control creation. This also keeps risk at a manageable level as you can then chip away at the migration piecemeal.

I agree. We have a lot of good code that works great right now. I don't want to break it all at once. We just want to refactor bit by bit so that eventually the system is more extendable and maintainable.

[oliverhutchison]

As for Application.services().getApplicationContext(), I thought that for now, we could use it to do things like allow a model instance to lookup it's business layer facade. Of course, I would like the container to do this for me through dependency injection but it would require quite a bit of refactoring. We want to take baby steps right now.

I'd be inclined to refactory your code so that it access the business facades using a service locator that delegates to an application context where needed and JNDI where needed. Once this is done you can then work through one service at a time converting over to DI.

Ollie

[cyboc]

I'd be inclined to refactory your code so that it access the business facades using a service locator that delegates to an application context where needed and JNDI where needed.

If I use Application.services().getApplicationContext() in the way I discussed (i.e. to lookup up business facades), is it necessary to make a separate service locator? I mean, isn't Application.services().getApplicationContext() sort of acting like a service locator for me in this case? Then in the ApplicationContext that it returns, I could initially use say SimpleRemoteStatelessSessionProxyFactoryBean to expose my existing session bean business facades and then slowly convert them to POJO business facades. Don't know if this makes any sense.

[oliverhutchison]

I find it's much cleaner to hide the app context behind a facade:

class ServiceLocatorImp implements ServiceLocator {
     public OrderService getOrderService() {
          return (OrderService) appCtx.getBean("orderService");
     }
}

This forces you to have a single point of control for all of you serivce lookups and also alows you to mix diferent lookup strategies behind the facade. For instance, you may still want to use JNDI for some services and the app context for others.

Ollie

[cyboc]

Okay, Ollie, thanks for all the tips!