Здравствуйте, Аноним, Вы писали:

А>я — анонимный топикстартер, отвечаю самому себе.
А>Похоже, что важность применения прокси классов обусловлена принципами построения SOA.

А>Тут принцип автономности, гласит:
А>

А>Каждая служба работает в собственной программной среде, на собственной ОС, реализована на определенном языке программирования и от этих факторов не зависит работа других частей системы, которые использую службу. Она ведет себя как независимый объект, обладающей собственным поведением, способный на взаимодействия с другими независимыми объектами. Поэтому реализация любой службы или же ее расположение в системе может изменена без нарушения общей работы системы ...

Не понятно причём тут принцип автономности. Каким образом использование прокси классов позволит Вам не менять логику клиента если изменился контракт?

А>И еще принцип "Службы описывают свой контракт и схемы сообщений, но не реализацию".
А>

А>Клиенты службы знают ее контракт (сигнатуры методов и их метаданные) и схемы данных, которые описывают сообщения службы и используемые данные. Информация о том, как реализована служба, ее клиентам не доступна и не нужна. Так же формальное описание контракта и схемы с помощью политик (policy) позволяет службам осуществлять проверку входящих сообщений. Как и в случае использования компонент (например, COM), так же имеющих контракт, особую значимость для работоспособности системы в целом имеет устойчивать контрактов.

Это естественно что общая сбрка не в коем случае не должна содержать какой либо код относящийся к реализации сервиса. Основная причина использования общих сборок — это возможность использовать код общий для сервиса и клиента который в противном случае пришлось бы либо дублировать на клиенте и сервере, либо выносить в отдельную сборку которая затем бы использовалась и клиентом и сервисом. Примером такой логики может мыть валидация свойств, методы Clone, Equals, перегрузка операторов ==, !=, и т.д. и т.п.

А>Ну а использование общих сборок нарушает эти прниципы. Насколько важно следовать этим принципам, наверно каждый решает сам, но что-то в них есть ..


На мой взгляд оба варианта a) и b) верные, всё определяется ситуацией.

К примеру если я собираюсь использовать сервис с клиентом который не WCF, то я использую варинт с прокси.

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

Здравствуйте, alexsoff, Вы писали:

A>Да, "обычные" сборки так просто не подключишь (из-за ограничений безопасности), у сильверлайта есть свой "тип" сборок.
Сильверлайтовские сборки зато подключишь к WCF сервису без проблем вообще.