CODEWITHSUNDEEP
c#angularjsmvvmknockout.jsservicestack
Lost
Lost

Reputation: 13575

Isn't DTO pattern ONLY useful when you combine it with some caching or MVVM?

This question is not to argue with the design but to understand how can this design pattern be fully leveraged. Now, just to summarize, my takeaway from ServiceStack's design docs was that using coarse-grained systems (DTO pattern) reduces back and forth from the server, along with other benefits like a small service surface area etc.

However, it begs a question that if I really want to take advantage of the coarse-grained Response DTO that the service stack service returns to me as a client, I need to re-use it as much as possible. I have to check existence of that object on the client side before going to server for the data. If I do not do it then I am not taking full advantage of the design and I could be better off with some thing like WebAPI which requires me to go to server each time.

Now, a few questions

  1. Is my assessment that a Coarse-grained DTO pattern when not combined with proper re-use mechanism is not optimally used or under used?
  2. This almost sounds like an MVVM client like (Angular, Knockout) which binds the object to a viewmodel to be re-used over and over is an ideal design for this. Is it a common practice to combine an MVVM client with ServiceStack DTO services?
  3. what if DTO pattern is being used in an environment with highly dynamic data. For example, using DTO for User Objects while bringing user and his game points each service call hoping to resuse user data and his GamePoint property when GamePoints are changing every second. The moment we brought the data, it is stale, would DTO pattern still be relevant in this environment?

Upvotes: 1

Views: 987

Answers (1)

mythz
mythz

Reputation: 143284

Returning coarse-grained responses shouldn't have any impact in what client technology or view pattern you use on the client, i.e. it's not forcing you to maintain a cache on the client.

In Single Page Apps I'll use ServiceStack's TypeScript Add ServiceStack Reference to fetch responses populated in typed Response DTOs which I'll maintain in the client state directly.

The Gistlyn code-base shows examples of this where it uses a generic JsonServiceClient and TypeScript DTOs to make API end-to-end Typed API Requests, exactly as you would when using any of other ServiceStack's supported Typed Clients (which is a benefit of ServiceStack's Gateway/DTO/Facade approach where API Requests are the same regardless of which language used).

Here's a typical example which fetches all the Variable Info from a Live Running C# Script and loads them directly to a Redux Store:

const client = new JsonServiceClient("/");
const request = new GetScriptVariables();
request.scriptId = state.activeSub.id;
client.get(request)
    .then(r => {
        store.dispatch({ type: "VARS_LOAD", variables: r.variables });
    });

Then to render the view I'll just inject the state maintained in Redux into React Components directly properties using TypeScript decorators, e.g:

@reduxify(
    (state) => ({
        inspectedVariables: state.inspectedVariables,
    })
)
class App extends React.Component<any, any> { ... }

So I'm using just data sourced from the populated DTOs directly and are not mapping them into any interim client View Model. So I don't even have to create the client View Models since they're automatically generated from TypeScript's Add ServiceStack Reference.

In (non-TypeScript) JavaScript databases, the JSON Response is returned as a vanilla JavaScript object which I'll use directly as above, the only difference is not having access to TypeScript's Type Safety for data access.

Some MVVM frameworks prefer a separate View Model, but this is independent if you're using ServiceStack or not, the benefit of using ServiceStack is that it provides a typed DTO for you to map onto your client view models giving you Type Safety benefits.

Upvotes: 3

Related Questions