• 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:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Inverting control so service layer calls gui

 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a trade object, it is currently saved to a file system. The details (filename, location) are filled in a dialog (swt). I'm introducing tests for this logic and I'm introducing a service layer. There will be a TradeService interface which will have methods to persist the trade.





When I'm running my unit tests, I will be subbing in a TransientTradeService which keeps a handle of trades in a HashMap. In production, we will use FileTradeService which actually saves stuff to disc.

Thing is, the FileTradeService needs the extra details mentioned. How to handle this? My solution was to invert control to the TradeService - essentially by passing in the current widget which will allow TradeService implementations which need more details from the user to be able to ask for them from the user.


and



On one hand seems neat, but also seems odd by service layer having a dependency on the ui. Is this something to be worried about? If so, any other solutions?

thanks, Don
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You have an interface for your various implementations of the service. That is the contract for clients. A client that works with one implementation should work with any of them. It's not fair for one implementation to pile on more requirements: oh, the client must also provide a dialog to get a filename.

Perhaps what you called "extra details" are not really extra, but always required by the interface and all implementations of the service. Your transient service can use these details to build a key for the hashmap. Your file system service can use them to read and write files.

Changing directions back to the optional dialog ... I'm not as comfy with this one ...

The service layer could own an interface for a DetailProvider, and maybe a default implementation that returns suitable hard-coded default values. The UI layer could optionally implement a DetailProvider that shows a modal dialog and register its implementation with the service. When the service wants details it calls the registered DetailProvider. Maybe you get a pop-up, maybe you don't. Now your dependencies run the right way but the flow is ... odd.
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks that helps.
 
reply
    Bookmark Topic Watch Topic
  • New Topic