WebService, чтобы иметь отдельные методы для заполнения свойств в составном классе?

Question

Я создаю веб-сервис для получения списка составных объектов.Если сложное подчиненное свойство каждого объекта в списке заполняется сразу, или это нормально, чтобы клиент запрашивал эту информацию по мере необходимости.

Пример:

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);

Это плохой дизайниметь другой метод в WebService как:

public List<InvoiceLine> GetInvoiceLines(string invoiceNumber)

и требовать, чтобы клиент сначала получил список всех сохраненных счетов-фактур (с пустым списком InvoiceLines в них, и ожидал, что они вызовут:

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

для имитации "отложенной загрузки".

Это похоже на хороший способ сэкономить на объеме, но за счет большего количества вызовов для получения данных при необходимости. Стоит ли этоэто или это какой-то антипаттерн?

Просто кажется неправильным возвращать наполовину заполненный объект ...

Заранее спасибо за любые указатели / ссылки.

Answer 1

Детализация интерфейса сервиса всегда является важным решением при разработке ваших сервисов. Поскольку вызовы веб-службы обычно являются сетевыми вызовами или, по крайней мере, внепроцессными вызовами, они относительно дороги. Если интерфейс вашего сервиса слишком мелкозернистый (или «болтливый»), это может повлиять на производительность. Конечно, вы должны учитывать ваше приложение и ваши требования при определении правильного уровня детализации. Компоненты программного обеспечения: Крупнозернистый или мелкозернистый , хотя немного сухое имеет хорошую информацию.

Просто кажется неправильным возвращать наполовину населенный объект ...

Я согласен.

В вашем случае давайте предположим, что InvoiceLines стоит дорого и не требуется большую часть времени. В этом случае вы можете инкапсулировать сводку или заголовок счета и вернуть эту информацию. Однако, если потребителю нужен полный счет, предложите ему сделать это.

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);

В целом, я предпочитаю избегать навязывания последовательности звонков потребителю услуги. сначала вы должны получить счет, а затем вы должны получить детали. Это может привести к проблемам с производительностью, а также к более тесной связи между приложениями.

Answer 2

Я не думаю, что это плохой дизайн, я думаю, что это компромисс, который вы должны рассмотреть.Что важнее: возвращение полного графа объектов или потенциальная экономия при передаче.

Если, например, у вас больше шансов иметь клиентов с несколькими сотнями или тысячами InvoiceLines, и вам нужны только тев очень специфических обстоятельствах кажется логичным разделить их так, как вы упоминаете.

Однако, если вам почти всегда нужен InvoiceLines, а вы обычно говорите только 10 случаев, тогдаимеет смысл всегда отправлять их вместе.

Answer 3

Веб-сервисы не должны быть "болтливыми": вы общаетесь по сети, а обмен запросами и ответами стоит времени. Вы не хотите требовать, чтобы клиент спросил десять раз, когда он мог бы спросить один раз.

Пусть клиент запрашивает все данные одновременно.

Если это приводит к проблемам с производительностью, тогда позвольте клиенту указать, какой объем данных он хочет получить, но все равно он должен быть возвращен за один вызов.