• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

POJO Design Style

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(Okay, value object, transfer object, model object, whatever you want to call them: basically an object that represents a "thing").

The "standard" way of developing a POJO follows the JavaBean spec:

- Data memembers
- Mutators (getters and setters)
- Empty Constructor

Then you can override equals() and hashCode(), implement Comparable, and all sorts of other fun things. One of these is to override toString() from Object to spit out some sort of String representation of the object. If it's not overriden, then toString() just spits out some default information about the Object.

Now, in the past, I've done things like create an interface called HashableEntity with a single method to export the data as a HashMap (trust me, it made sense at the time...), or other representations.

Now I find myself wanting to create an interface called something like SoapEntity, with a single method called toSoapMessage() (obviously returning an object of type SOAPMessage). Now, this is a bit more heavyweight than my previous examples, requiring the import of all sorts of stuff from the javax.xml.soap package.

The other option is a Utility class or Service class method to take the POJO and return a SOAPMessage.

(I suppose one other option would be a Decorator for the POJO, as well).

What would be the arguments for or against having the logic in the POJO (other than the overhead I mentioned previously)? I feel that putting the logic into the POJO would be okay, as we're not operating on the data, just representing it differently when asked.

Jason
[ November 18, 2008: Message edited by: Jason Ferguson ]
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jason,
Hmm. Interesting question because there are tradeoffs either way. The first thing I did was confirm that SOAPMessage was in standard Java (and not requiring a jar.) If it was in another jar, I absolutely wouldn't add the method to the POJO as it would force an external dependency just to use my POJO.

On some level, I like the idea of keeping the SOAP message creation in a separate layer of the application dedicated to web services. A significant reason is that changing that SOAPMessage likely means changing other web service code/the web service API.

On another level, I like having all the code together on the object so I remember to update the SOAPMessage when I change fields on the object.

Overall, I think keeping it separate is a stronger pull in my mind because SOAPMessage is a published API to someone outside the application. (I do have a couple POJOs that output JSON for JavaScript processing, but that's within my app so I can change the JSP/JavaScript if the format changes.)

I look forward to reading more thoughts on what people would choose and why!
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This certainly is an interesting question! I think I broadly agree with Jeanne . In my mind SOAP is simply a transport mechanism for your POJO and is simply not part of that POJO's business 'logic'. The question I normally ask my self is some thing like (assuming you object is an Invoice):

"Is SOAP Message a integral part of Invoice?"

I also strongly agree that you do not want your POJO dependent on a third party library, what if that library were to change? You'd have to dive deep into you POJO code to 'fix' things, e.g. You have no decoupling.

I can also see the flip side where you 'know' that you're always going to use SOAP and that editing the code etc is much easier in one place.

Anyone else? The more opinions the better!
 
reply
    Bookmark Topic Watch Topic
  • New Topic