tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/4249-struggling-with-services-and-best-practicesRobotlegs: Discussion 2013-11-15T11:45:49Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/297522972013-11-01T21:23:50Z2013-11-01T21:24:07ZStruggling with Services and Best Practices<div><p>I have been struggling with understanding how to best implement
my applications Services and I would love some advice.</p>
<p>Three Service Questions:</p>
<p>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?</p>
<p>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</p>
<p>Question 2: Are there best practices for Service and Model
interaction?</p>
<p>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.</p>
<p>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.</p>
<p>Question 3: Advice on RBL Commands Pattern and using
Promises?</p>
<p>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.</p></div>hays.clarktag:robotlegs.tenderapp.com,2009-10-18:Comment/297522972013-11-04T16:41:28Z2013-11-04T16:41:28ZStruggling with Services and Best Practices<div><p>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.</p>
<p>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.<br>
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 ;)</p>
<p>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?<br>
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?</p>
<p>First, see if [1] Shaun's or [2] Stray's answers are of any help
to you, and we can then continue the discussion:</p>
<p>[1] <a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/38-service-with-a-large-api#comment_17269563">
http://knowledge.robotlegs.org/discussions/robotlegs-2/38-service-w...</a></p>
<p>[2] <a href=
"http://knowledge.robotlegs.org/discussions/questions/327-one-service-for-many-actions#comment_3395312">
http://knowledge.robotlegs.org/discussions/questions/327-one-servic...</a></p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/297522972013-11-04T20:27:18Z2013-11-04T20:27:18ZStruggling with Services and Best Practices<div><p>Thanks! Both of those articles are very helpful.</p></div>hays.clark