• 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

What's the right J2EE pattern

 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This follows the question I asked here.
Kyle pointed out that when I want to do a tranfer between two account objects (e.g. one gives moeny and gets stick, the other gives stock and gets money), I should have those accounts represented as entity beans and use a stateless session bean to take both of them and do the tranfer. Now this is client initiated, meaning client A says he wants to execute a trade between his account and account B (which had a standing order to allow this trade, hence client B is not notified of the trade until it has completed).
Client A can't directly access the entitiy bean which is client B's account. Instead, we were going to have each account have a unique ID and when client A requests the trade, it gives the unique ID of client B's account. (BTW, security isn't a major concern here.) So basically, the session bean will do a lookup to get a reference to client B's entity bean representing his account. But this kinda defeats some OO principles, since effectively we make these objects global, accessible to anyone who wants to ask for them. I've used this pattern in other places on occasion, but not with EJBs. We'll be doing this with accounts and a few other objects shared by each user. Is this an appropriate pattern to use? Is there a better one?
Thanks for any help.

--Mark
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would probably create a "Transfer" object that you give both the key for "Buyer" and the key for "Seller" and that looks them both up and does the transfer. That way neither the buyer nor the seller know the details of the other -- they are both hidden in the Transfer.
Kyle
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, that sounds like what I was proposing. I'm not too worried about the buyer or seller finding the other's info (this is just a simulation, if some MBA student really wants to hack it, well, they can). Rather, I was just concerned about breaking OO principles by having a lookup to grab an object--this object may be used by other people, at other times.
By having this class that can return an account object to anyone who requests it, concepts such as abstraction layers and low coupling can be ruined. Lazy programers (not me, of course, I'm never lazy :-p ), don't have to owrry about passing objects around to get them to the classes who need them, then can just request them directly. You effectively turn these classes into "global variables."
I have used this techinque in J2SE projects. Sometimes it does make sense to have such a public repository. While there are no programmatic constraints on data access (everything is public), the system architect tells everyone to follow a certain design principle that these clasees may onyl be accessed under certain circumstances in certain ways, and he carries a big rubber hose to enforce those principles :-)
In J2EE, is it ok to do the same thing, or is there a better way to create such a repository? (Again, security isn't a major concern, but good OO design is.)
--Mark
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic