Best practice for queries and WCF Service

Question

What would be the best practice for the following scenario:

There´s a grid that will be filled and must be changed according to each row. For instance, there´s a grid filled with products, then according to each product one of the columns will be dynamically populated. Is it better to return from the service all the productdetail table and query it on the client side or have a method on the service that will return only the data needed? The latter would mean that if there are n number of products on the grid, there will be n requests to that service method.

My dilemma is that for some of the users the table will be relatively small and sending it to the client might not be a big deal, but other users do have a considerable amount of rows that would be returned (more than 15k).

Thanks for any insight you may bring.

Answer 1

You could make your service implement some sort of paging, and allow the client to request the number of records they want (usually a starting index and a count, or something like that). You could cap the page-size at a certain limit so that you don't end up having to serve a huge request.

Using something like this, you should be able to find a nice balance between the number of calls being made vs. the size of the data being served in each request.

Answer 2

Sounds like network latency is the issue here. If you've got 100 products and (say) a 0.2s round trip time, that's 20 seconds to load all the data. Minimize your service calls as much as possible and if necessary remap the data into a more suitable structure in your client.

Edit: Another idea, if it's possible in your situation, is to compress the data between your client and service. Have a look at this forum post. You'll see big gains if you're pushing around heaps of XML.

Answer 3

I'd suggest creating some sort of ViewModel on the server to tailor the data for the client. This is similar to your second option; however, it's not done on row by row. It's a batch operation on the server side which preps the columns so the view doesn't need any special logic.

I feel manipulating data on the client side can be tricky because there's so many variables- browser, os, computing power. You control the server, so leverage what you control as much as possible.

Good luck.

Answer 4

The topic you have stumbled upon is warmly debated topic of granularity on service-oriented architecture. SOA is like a mystic mammal being discussed by blind men, but that's not really the point.

The "best practice" of the trend is coarse-grained services, a departure from object-oriented. Consider your services to be exchanges of documents, in which you put in everything you need to get things done.

As Andy White has suggested, if the data gets too big you'd need some sort of filtering or paging.