I have upgraded my app to use the Jaxor Entities in my Struts ActionForms instead of an ADM (Anemic Domain Model) like I said I would do in a previous post. I didn't know if it would work or not because I am still learning Jaxor. Well, Jaxor pulled through again and provided the necessary methods for me to pull this off. It was very exciting because I had tests that worked. So I actually got to practice TDD. Granted I am not doing Test First, I still can't get my brain wrapped around that, but I think I see it coming in the near term. Keeping that green bar hopping across my JUnit window was lots of fun.
Anyway, back to Jaxor and Struts. My ActionForm is very complex with 5 private member variables<sarcasm> 4 of the 5 are Jaxor Entity Objects and the 5th is a boolean. I created a Business Delegate Object that the Action will call. At work, our Actions have started getting very complicated because they are storing the business logic. So, this time I am going to take my own advice and put a Business Delegate class out there to handle the details and allow my Action to play traffic cop just as he should.
The primary reason for refactoring my ActionForms to use Jaxor Entities was to get rid of the need to copy the properties from one object to another. Having to maintain two objects with the exact same properties was just... Dumb. While doing this, I found more improvements and significantly improved the readability of my code. Since Struts will be sending in new Base Entities that are not really new instances of the Entity (IE no JaxorContext) I came up with a really nifty method that takes an Entity, sets the JaxorContext, calls insert(), commit()'s and then returns the entity. A very sexy 4 lines of code that is currently used in 3 different places, but will end up being used often.
Posted by carl at November 27, 2003 06:36 AM
Very interesting usage of Jaxor Entities. I've built a few webapps with Jaxor, but I've always used "dumb" forms. So how did you design the form? Just a regular ActionForm with a single instance variable that is the entity?
For the JaxorContext, are you using a servlet filter?
I don't know why it didn't dawn on me before to do it the way you describe. I think I just might steal your idea. ;)
Mike
Posted by: Mike Rettig at November 27, 2003 07:15 PM
Exactly right about the ActionForm. I have a ClientForm that has-a ClientEntity, has-a PersonEntity (point of contact), has two AddressEntity, one for the Client and one for the POC and then a boolean that allows the user to say, use the same Address for the Client and the POC.
Since I went with this whole Business Delegate strategy, I start the JaxorContext going into the Business Delegate and end() it before leaving. Right now the start and end are the first and last lines of the Business Delegate's method. Since that would have to be repeated, I should factor that up to a Base Action.
Actually...
Until this very moment I have never understood why putting the Context into a Filter was desired. It is for the lazy loading that may be done at the JSP level right?
Posted by: Carl Fyffe at November 27, 2003 08:29 PM
If the context is set in the filter, then it gives you a little more flexibility. It does solve lazy loading issues and it allows you to do queries within the jsp.
This also has transactional implications. If there are rendering problems with the JSP, then the filter will receive the exception and rollback the transaction.
I think the biggest advantage is with lazy loading. In the Action, you don't know what data the jsp needs for display.
I've used a filter with great success. Once the filter is in place, you never have to worry about transactions or JaxorContext scope problems.
Posted by: Mike Rettig at November 28, 2003 03:32 PM
Comments