WebService to have separate methods for populating properties in composite class?

I'm building a web-service to retrieve a list of composite objects. Should a complex sub-property of eac开发者_JAVA百科h object in the list be populated at once or is it OK to have client request that info as needed.

Example:

class InvoiceLine
{
  string ServiceDescription;
  decimal ChargeTotal;
}

class Invoice
{
  string InvoiceNumber;
  string CustomerNumber;
  List<InvoiceLine> InvoiceLines;
}

//Returns all invoices send to this customer
public List<Invoice> GetInvoices(string customerNumber);

Is it bad design to have another method in WebService as:

public List<InvoiceLine> GetInvoiceLines(string invoiceNumber)

and require client to first get a list of all saved invoices (with empty list of InvoiceLines in them, and expect them to call:

invoices[0].InvoiceLines = webService.GetInvoiceLines(customerNumber);

to simulate a "lazy-load".

This seems like a good way to save on volume but at the expense of more calls to get data when needed. Is this worth it or is that an anti-pattern of some sort?

It just doesn't seem right to return a half-populated object...

Thanks in advance for any pointers / links.

Service interface granularity is always an important decision when designing your services. Since web service calls are usually network calls or, at the very least, out of process calls they are relatively expensive. If your service interface is too fine grained (or "chatty") then this can affect performance. Of course, you need to consider your application and your requirements when determining the correct level of granularity. Software components: Coarse-grained versus fine-grained although a little dry has some good information.

It just doesn't seem right to return a half-populated object...

I agree.

In your case let's assume that InvoiceLines is expensive to retrieve and not required most of the time. If that is the case you can encapsulate the invoice summary or header and return that information. However, if the consumer needs the full invoice then offer them the ability to do that.

class InvoiceLine
{
  string ServiceDescription;
  decimal ChargeTotal;
}

class Invoice
{
  InvoiceSummary InvoiceSummary;
  List<InvoiceLine> InvoiceLines;
}

class InvoiceSummary
{
  string InvoiceNumber;
  string CustomerNumber;
}

public InvoiceSummary GetInvoiceSummary(string customerNumber);
public Invoice GetInvoice(string customerNumber);

In general, I prefer to avoid imposing a sequence of calls on the consumer of the service. i.e. First you have to get the Invoice and then you have to get the Details. This can lead to performance issues and also tighter coupling between the applications.

Web services should not be "chatty": you're communicating over a network, and any request/response exchange costs time. You don't want to require the client to ask ten times when he could ask once.

Let the client request all of the data at once.

If that turns out to be a performance problem, then allow the client to specify how much of the data they want, but it should still all be returned in a single call.

I don't think it's bad design, I think it's a trade-off that you have to consider. Which is more important: Returning a complete object graph, or the potential transmission savings.

If, for example, you're more likely to have customers with several hundred or thousands of InvoiceLines and you only need those in very specific circumstances, then it seems very logical to split them up in the way you mention.

However, if you almost always need the InvoiceLines, and you're only usually talking 10 instances, then it makes more sense to always send them together.