Multiple WCF calls for a single ASP.NET page load

Question

I have an existing asp.net web application I am redesigning to use a service architecture. I have the beginnings of an WCF service which I am able to call and perform functions with no problems. As far as updating data, it all makes sense. For example, I have a button that says Submit Order, it sends the data to the service, which does the processing.

Here's my concern: If I have an ASP.NET page that shows me a list of orders (View Orders page), and at the top I have a bunch of drop down lists for order types, and other search criteria which is populated by querying different tables from the database (lookup tables, etc). I am hoping to eventually completely decouple the web application from the DB, and use data contracts to pass information between the BLL, the SOA, and the web app. With that said, how can I reduce the # of WCF calls needed to load my "View Orders" page? I would need to make 1 call get the list of orders, and 1 call for each drop down list, etc because those are populated by individual functions in my BLL.

Is it good architecture to create a web service method that returns back a specialized data contract that consists of everything you would need to display a View Orders page, in 1 shot? Something like this pseudocode:

public class ViewOrderPageDTO
{
  public OrderDTO[] Orders { get; set; }
  public OrderTypesDTO[] OrderTypes { get; set; }
  public OrderStatusesDTO[] OrderStatuses { get; set; }
  public CustomerListDTO[] CustomerList { get; set; }
}

Or is it better practice in the page_load event to make 5 or 6 or even 15 individual calls to the SOA to get the data needed to load the page? Therefore, bypassing the need for specialized wcf methods or DTO's that conglomerate other DTO?

Thanks for your input and suggestions.

Answer 1

I might suggest to keep it simple at first, and just make a single call for every type of entity you need to retrieve. If you think about it, when a browser loads a web-page, it makes a ton of HTTP requests to fetch the html and all the content files, so it's not terrible to call a few service methods in that process. As long as the services are quick and small, it should not become too much of a problem.

If you are seeing performance problems, I would focus in on those, rather than trying to pre-optimize anything. You could look at lumping several service calls together, or implementing a caching layer either on the server or client side.

Answer 2

It is absolutely a good design to have web service method/operation dedicated to providing the complete set of data required to display a particular "business object."

In fact, that type of design is the very essence of web services and SOAs. You are providing intelligence and abstractions, not mere CRUD-like data access methods.

This will also perform much, much better than making 5 or 6 web service calls from a single web page. 5-6 calls are a lot, especially when you're able to reduce that to just 1. Web Service calls tend to be expensive, at least compared to basic data access or cache lookups, and you really want to reduce the amount of "chatter" if possible.

Your first instinct was correct. Go with the coarse-grained web service that gives you everything you need.