Best approach to Service classes with TONS of methods
Beau N. Brewer
via web
We have an application with a number of service classes that are organized by user type (Flex and PHP side.) Each class has an estimated 30+ methods. Looking at a number of different examples, like the FlickerImageGallery, I see the service classes contain the code to make the Async calls and handlers for those calls in a single class.
I'm thinking my service classes are going to get unruly if each method has a result and fault handler. Am I wrong to think my service classes should be CRAZY HUGE?
In the past I've had the services return an AsyncToken to the command which can then add responders/handlers that are located within the commands. I'm not sure if this is a terrible idea, but I think it started doing it this way to keep my service classes size down.
Cairngorm had service delegates that would be instantiated in the commands. The commands implemented IResponder so you could pass a ref to it in the constructor of the service delegate.
Thoughts here? Suggestions? Ideas?
Comments are currently closed for this discussion. You can start a new one.
2 Posted by odoe on 25 Jun, 2010 03:59 AM
I have a similar situation in one of my applications where a web service has a dozen or so methods. In my app, I just decided to split the single service among 3-4 Service classes and group them by type as best as possible to keep from having a single cluttered class.
Passing Command functions via AsyncTokens is perfectly viable. I've done it in a couple of cases, but in a larger app, I feel more comfortable letting the service do the bulk of the work.
There are also a couple of discussions on an AsyncCommand, but I have not used it.
http://knowledge.robotlegs.org/discussions/questions/115-using-the-...
Stray closed this discussion on 12 Feb, 2011 01:18 AM.