Tuesday, September 2, 2008

model refactoring project continued

Im working on a small update to some core logic in one of my frequently visisted objects. A couple of the updates, including to the controller (this is a machii application) are requiring me to bring along some other changes i made a couple months ago and have been sitting waiting for something like this to come along. I could have made a branch in our source control software to deal with only the changes to the current project, but chose not to.

When i looked back at the changes i made a couple months back, i noticed the coldspring integration i had started. I had integrated a few components into the coldspring configuration file and injected them into their dependent service components. All good! I decided to integrate the current component and its dependent components too. I was pleasently surprised when it only took me about 15 minutes to do this work. Ive got my head around coldspring a bit now and new just what i wanted to do and why. The changes are listed below.

1 - identified the collobarating objects and gave them bean definitions in the config file
2 - identified the dependent object and gave it a bean definition.
3 - injected the two colloborating objects (components) into the dependent object
4 - added set methods for the collaborating components in the dependent object that - removed the init method in the service
6 - tweaked the colloborating components to not require a property on init, changed the default to no and provided a default value. If a value is passed, it will take it but does not require.

Each of these components are singletons, which are perfect for the coldspring container. They have no state and simply provided data that is kept in a related bean component. I caught myself trying to add the bean to the coldpring config. file, but stopped when i clued in to the bean is not a singleton, it has state that updates frequently. I ended up with a method in the service to the bean that checks to see is a session scoped var exists, if not, creates one and used it to update the bean during the user session.

Then i moved into part 2 of this operation

As i am looking at the service, i see where i should have put certain methods into the DAO not the Gateway. I think initially, i only had a gateway component, but as the requirements grew, so did the component. Now i have a DAO and am putting requests for a single rec or data item into it, while leaving the gateway as the aggregator or record sets.

Finally, im looking at this wiht object eyes

and seeing what can i move to the bean and keep the persistence stored in the bean.

No comments: