Struggling with Services and Best Practices
I have been struggling with understanding how to best implement my applications Services and I would love some advice.
Three Service Questions:
Question 1: What are good strategies to breakup very large Service APIs? Are there rules of thumb on How and When to breakup Service APIs?
Most of the Service examples I have found are rather contrived and just show wrapping small services with just 6 or 7 commands, IE ITwitterService. In those example there is single Class that does all things Twitter related. If I were to make a single Interface for all the server commands it would be an interface with hundreds of methods, which seems to completely fly in the face of the Single Responsibility Principle. On the flip size, if I were to make a Service for each command we have hundreds of Services. Does anyone have advice? :D
Question 2: Are there best practices for Service and Model interaction?
Originally I thought that decoupling Services from Models updating could be base done in a Command. Now I am not so sure. I have many commands that inject a service and are detained() while they do their Async stuff is done they chain to a Command that will manipulate the Model and the release() themselves. This 'works' but it seem bad long term because commands end up with a lot of 'service' config stuff, you have class explosion, and you end up needing Static variables to do blocking. It's also unclear what commands are Service related vs Model related.
In Joel Hooks RBL examples he has Models being injected into a Service and the Service directly manipulates that. It's very clean, simple, and obvious what his happening. But is it bad that Service/Model coupling? You seem to loose the portability of the Commands.
Question 3: Advice on RBL Commands Pattern and using Promises?
I am very new to Promises and while I like them they seem rather problematic to use with the RBL command pattern. As soon as I started implementing Services that return a Promise it's super tempting to have Mediators talk directly to Services. One option that I have not explored is having a Command return the Service Promise via a callback.
Comments are currently closed for this discussion. You can start a new one.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Ondina D.F. on 04 Nov, 2013 04:41 PM
I'm sorry that you haven't got an answer until now. As for myself, I've had a prolonged weekend away from my computer.
I don't know if I can add anything new to what has been discussed so many times on this forum about Services and Models over the past years.
As you are well aware, very large Service APIs are not good. You want to remedy that, but at the same time you're afraid you'll end up having too many separate Services ;)
What is your Service supposed to do, what kind of data source is it accessing (file system, web services, LSO...)? Why are there so many different methods? Is it a 3rd -party API?
Is your application having lots of different functional areas, that require accessing different data sources, or do they have a lot in common, like some SCRUD operations?
First, see if  Shaun's or  Stray's answers are of any help to you, and we can then continue the discussion:
2 Posted by hays.clark on 04 Nov, 2013 08:27 PM
Thanks! Both of those articles are very helpful.
Ondina D.F. closed this discussion on 15 Nov, 2013 11:45 AM.