Возврат бизнес-объекта из веб-службы

Question

Изображение, если хотите, следующий сценарий:

• BusinessObjects.dll содержит класс «BusinessObject»
• Ссылки WinClient BusinessObjects.dll
• Ссылки на веб-службы BusinessObjects.dll

Веб-сервис имеет метод:

public BusinessObject GetBusinessObject()
{
  BusinessObject result = new BusinessObject;
  result.Name = "MyBusinessObject";
  return result;
}

Этот метод вызывается WinClient.

Когда я добавлю ссылку на WebService, будет создан прокси-класс. Поэтому, если я получаю доступ к BusinessObject из WinClient, вот так:

BusinessObject bObj = service.GetBusinessObject();

тогда bObj НЕ является тем же объектом в BusinessObject.dll, но фактически является прокси.

Существует документальное решение, описанное здесь - http://ryanfarley.com/blog/archive/2004/05/26/737.aspx

Мой вопрос - это хорошая идея? Или объекты, возвращенные из службы ВСЕГДА, должны рассматриваться как простые DTO? Поэтому, если нам нужна логика, мы должны скопировать значения в РЕАЛЬНЫЙ businessObject. Но как насчет производительности, сказавшейся на этом - стоит ли беспокоиться об этом?

Любые отзывы приветствуются, спасибо.

Answer 1

Зависит от того, важна ли «чистота» услуги. Если клиент only будет вашим exe, то я бы не стал волноваться; затем вы можете получить «интеллектуальный» (если вы понимаете, что я имею в виду) объект на клиенте (например, реализующий IDataErrorInfo для проверки) без какого-либо дублирования кода.

Но если вам нужна поддержка специальных клиентов, вам следует придерживаться базовых DTO (прокси-объектов).

Обратите внимание, что если вы хотите пойти по этому пути (совместное использование сборок), то вы можете сделать это в WCF без каких-либо изменений; svcutil и в среде IDE предлагаются варианты повторного использования типов из существующих сборок, хотя на самом деле это вам даже не нужно (вы можете получить прямой доступ к каналу). Все, что вам нужно, это правильные данные конфигурации в app.config, чтобы он знал, где найти службу.

Answer 2

Да, всегда используйте DTO или что-то подобное.

Повышение производительности при копировании данных в памяти, вероятно, будет тривиальным по сравнению с производительностью сети, в которой данные собираются пройти.