Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here's the application structure I found workable:</p> <ul> <li>Application is split into modules (Prism but can be anything) - module per vertical function. </li> <li>Every module has its own set of service client classes (generated by slsvcutil)</li> <li><p>For every service client partial class I have another generated partial class where for every service method I have a version that returns IObservable. </p> <p>E.g. if my service client has a method <code>GetAllMyDataAsync()</code> and event <code>GetAllMyDataCompleted</code> the generated method signature will be <code>IObservable&lt;MyDataDto[]&gt; GetMyData()</code> This method will deal with subscribing/unsubscribing to an event, authentication, error handling, and other infrastructure issues. </p> <p>This way web-service call becomes simply: </p> <p><code>new MyServiceClient().GetAllMyData().Subscribe(DoSomethingWithAllMyData)</code></p> <p>With this I can easily join data from multiple requests, e.g. (strictly for demonstration purposes, don't try this in real app):</p> <pre><code>var des = (from d in new MyServiceClient().GetMyDataItem() from e in new MyServiceClient().GetDataItemEnrichment(d) select new EnrichedData { Data = d, Enrichment = e}); des.Subscribe(DoSomethingWithEnrichedData); </code></pre></li> <li><p>Once application gets more complex (e.g. data is shared by multiple components, you add messaging that dynamically updates initially retrieved data, etc.) it's helpful to add another element in the stack - Model. </p> <p>Therefore if I have a service <code>MyDataService</code> I'd have a model class called <code>MyDataServiceModel</code>. It will be registered in the container as singleton and it will be injected into viewmodels that needs it. Thus viewmodels talk to this class when they need data (so rather than calling <code>MyServiceClient.GetAllMyData</code> it would call <code>MyDataServiceModel.GetAllMyData</code>. </p> <p>This way viewmodels are completely independent of WCF stack (easier to mock, easier to test) Additionally these model classes take care of:</p> <ul> <li>data transformation from/to DTO </li> <li>enriching and combining data (one model method may join data from more than one request) </li> <li>handling issues like throttling (e.g. typical scenario, user selected something in a combobox, it caused a request to be sent to a server to retrieve a data for that selection, while that request is being exected user made another change, but for some reason responses came out of order), etc.</li> <li>combining data pulled on initial load via WCF with data pushed by the service during the session</li> </ul></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload