Нет определенного ответа на эту проблему, и это также причина, по которой вы не нашли ни одного.
Собираетесь ли вы строить сервисы, обеспечивающие операции CRUD? Как правило, это означает, что ваши службы смогут возвращать, вставлять, обновлять и удалять сущности такими, какие они есть = вы всегда будете предоставлять всем клиентам всю сущность или одну точно определенную сериализуемую часть сущности. Но как только вы это сделаете, стоит проверить WCF Data Services.
Собираетесь ли вы разоблачить бизнес-фасад, работающий с юридическими лицами? Фасад обеспечит реальные бизнес-методы, а не только операции CRUD. Эти методы позволяют получить некоторый объект данных и разложить его на несколько объектов в бизнес-логике. Здесь имеет смысл использовать конкретный DTO для каждой операции. DTO будет передавать только данные, необходимые для операции, и возвращать только дату, разрешенную для клиента.
Очень простой пример. Предположим, что ваши сущности хранят информацию типа LastModifiedBy. Это, вероятно, информация, которую вы хотите передать клиенту. В первом сценарии у вас есть один сериализуемый набор, так что вы передадите его обратно клиенту, а клиент передаст его обратно в службу. Теперь вы должны убедиться, что клиент не изменил поле, потому что у него, вероятно, не было разрешений для этого. Вы должны сделать это с каждым полем, которое клиент не имел разрешения изменить. Во втором сценарии ваш DTO с обновленными данными просто не будет включать это свойство (= специализированный DTO для вашей операции), поэтому клиент вообще не сможет отправить вам новое значение.
Это может быть как-то связано с тем, как вы хотите работать с данными и где будет применяться ваша реальная логика. Это будет на службе или на клиенте? Как вы будете гарантировать, что клиент не будет публиковать неверные данные? Вы хотите ограничить передачу неверных данных по логике или по конкретным переданным объектам?