Is Service Stack's DTO pattern really helpful?

Question

Well, I have used ServiceStack ORMLite in the past and now trying my hands on ServiceStack RESTful DTO pattern. I have used WCF/Web API in the past and to me having a service with different methods is the natural paradigm where you just make an RPC call whenever you need something. However, while reading about Servicestack's DTO pattern and it flagship argument :

When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.

The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.

The argument itself begs a lot of questions for me:

1. Does it mean that when a page loads which deals with Product object then we just bring all the data from Product table and keep it around for any Re-use(A potential re-use)?
2. What if one call Get all ends up being a lot of data? Can I not argue that sometimes when "GetAll" in one call brings a lot unnecessary data then going back to the server whenever needed is a better idea?
3. Also, it sounds to me that the Pattern is assuming that the client side developer WILL take advantage of it being DTO pattern. The service would be called once and returned data would be kept in memory for a long some time for further re-use. What if I am a bad developer and completely disregard the fact that this service is designed for a lot of re-use and ends up calling service every time any data is required. Wouldn't that be two edged sword?

Answer 1

The Data Transfer Object pattern isn't the only pattern ServiceStack's message-based services benefits from, it also adopts the related Remote Facade and Service Gateway pattern, this previous answer describes benefits it gains by leveraging clean DTOs and the docs lists Advantages of message-based Services.

Does it mean that when a page loads which deals with Product object then we just bring all the data from Product table

No Coarse-grained interfaces is not about bringing the entire Product dataset and caching on the client. You'd only return that data that's useful for that for that context, so if you need info about a product then you'd return the product and related metadata that's useful for the client when viewing a product, e.g. category/supplier info to prevent the client having to perform multiple service calls to fetch what they need which reduces latency, reduces the API surface area that needs to be maintained/documented/learned, makes the same service more reusable for different client use-cases with a single cache entry supporting multiple clients and less likely backend Services will need to be rewritten when UI changes - as opposed to client-specific RPC calls.

What if one call Get all ends up being a lot of data?

No don't bring down the full dataset when you just need summary search results. Optimize searches to return just the data that needs to be displayed on the search results. When viewing a single dataset, you can fetch the Products related metadata then.

What if I am a bad developer and completely disregard the fact that this service is designed for a lot of re-use and ends up calling service every time any data is required. Wouldn't that be two edged sword?

It's less likely that API consumers are going to hunt down different APIs to call when their existing Services are returning the data they need. Having fewer more coarse-grained API calls naturally lends itself to fewer calls that's easier to cache which reduces latency even for naive developers who don't know how to construct efficient concurrent API calls.