title: Controller <-> Service component interaction
body: <p><strong>UPDATED:</strong></p>
  
  <p>I have a desktop application, with the following components interacting:</p>
  
  <ul>
  <li>Winforms UI.</li>
  <li>Service (in-process C# class that contains business logic to actually <strong>do</strong> stuff).</li>
  <li>Controller (C# class that coordinates events raised by the UI and calls service methods).</li>
  </ul>
  
  <p>If a controller asks a service to do something, but that service needs something more from the controller first (i.e. data that the controller must use a UI to obtain from the user), <strong>how should the service get the controller to do so?</strong></p>
  
  <hr>
  
  <p>I'm comfy with the concept that</p>
  
  <ul>
  <li>User communicates with </li>
  <li>UI which communicates with </li>
  <li>Controller which communicates with</li>
  <li>Service component (not to be confused with a web service or out-of-process service) which communicates with</li>
  <li>Data/Repositories which comm...</li>
  </ul>
  
  <p>and so on.</p>
  
  <p>However, with regard to the Controller communicating with the Service, what method is best for this?  Should:</p>
  
  <ol>
  <li>Service methods be fairly fine-grained, and throw exceptions if something's not right so the controller knows whether to move on or tell the user something went wrong?  Or...</li>
  <li>Service methods return objects that the controller can inspect to decide what to do next?</li>
  </ol>
  
  <p>I like the first option, because the second could mean class-explosion, where you need a <code>ServiceResult</code>-style class for each Service method.</p>
  
  <p>I ask because of course the Service component cannot tell the UI what to do, only the controller can, but the controller doesn't know what to tell the UI without getting some feedback from the Service.</p>
  
  <p>What do you think?</p>