Re[2]: WCF. Прокси-классы vs. общие библиотеки. - .NET

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

А>Кто-нибудь может объеснить почему именно а) или b) нужно применять, какие преимущества, недостатки
А>Для b) есть уже одно преимущество: это наличие логики, которая может использоваться как на сервере, так и на клиенте
Я использую вариант b, большей частью потому что не люблю генерилки.
А преимущество в виде расшаренно кода сомнительно, т.к. контракт не должен содержать логику. А если очень хочется, то можно расшарить сборку с extension методами.

Привет всем.
a) Клиент к службам WCF на основе WSDL может построить прокси классы, и работать с ними для транспортировки данных.
b) Клиент может подключить библиотеку с типами, и использовать их.

Кто-нибудь может объеснить почему именно а) или b) нужно применять, какие преимущества, недостатки

Для b) есть уже одно преимущество: это наличие логики, которая может использоваться как на сервере, так и на клиенте

А>Я использую вариант b, большей частью потому что не люблю генерилки.
Т.е. выбор основан на интуитивных предпочтениях, без учета каких-то так технических особенностей (о которых я еще не знаю)?

А>А преимущество в виде расшаренно кода сомнительно, т.к. контракт не должен содержать логику. А если очень хочется, то можно расшарить сборку с extension методами.
Если расшаривать сборку, то помещена ли логика в extension или в обычные классы, сдается мне не играет существенной роли.

Спасибо за мнение

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

А>Т.е. выбор основан на интуитивных предпочтениях, без учета каких-то так технических особенностей (о которых я еще не знаю)?
угу, поэтому тоже было бы интересно других послушать

А>Если расшаривать сборку, то помещена ли логика в extension или в обычные классы, сдается мне не играет существенной роли.
на мой взгляд, с эстетической точки зрения не очень

т.к. контракт данных — это именно контракт данных, а не контракт + логика

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

А>Привет всем.
А>a) Клиент к службам WCF на основе WSDL может построить прокси классы, и работать с ними для транспортировки данных.
А>b) Клиент может подключить библиотеку с типами, и использовать их.

А>Кто-нибудь может объеснить почему именно а) или b) нужно применять, какие преимущества, недостатки

А>Для b) есть уже одно преимущество: это наличие логики, которая может использоваться как на сервере, так и на клиенте

У варианта a есть ряд минусов:
1. Вообще говоря автогенерённые код коммитить в репозиторий — не айс, если ты этот код руками, конечно, не правишь. Imho такой код должен генериться на этапе сборки.
2. Дополнительные трудности при рефакторинге — чтобы переименовать или удалить поле в транспортном объекте, нужно сделать это на серверной части, обновить ссылку на сервис, поправить клиентский код.
3. Генератор прокси-классов (aka serviceutil.exe) иногда глючит.

Вариант a, на мой взгляд, имеет смысл применять когда серверная часть не в ходит в наш проект, к примеру это один из сервисов Google или другой сторонней организации.

PS. В одной сборке лучше не смешивать контракт сервиса и логику работы с транспортными объектами.

_>У варианта a есть ряд минусов:
_>1. Вообще говоря автогенерённые код коммитить в репозиторий — не айс, если ты этот код руками, конечно, не правишь. Imho такой код должен генериться на этапе сборки.

Не понял в чем проблема с сохранением генерированного кода в VCS? Такой код должен генериться на этапе сборки чего — Сервиса или Клиента? А основые правки делаются в partial классах, их то коммитить можно?

_>2. Дополнительные трудности при рефакторинге — чтобы переименовать или удалить поле в транспортном объекте, нужно сделать это на серверной части, обновить ссылку на сервис, поправить клиентский код.

Да это вызывает некоторые неудобства

_>3. Генератор прокси-классов (aka serviceutil.exe) иногда глючит.

Если используются классы с использованием атрибутов — DataContract/DataMember — глюков не встречал ни разу, все отрабатывает чисто. Глюки были однажды, когда я использовал DataSet, так там просто, эта утилита несмогла разрешить некоторые зависимости, намешала два сериализатора в одну кучу. Решалось путем использования svcutil вручную, нужно было указать некоторые параметры явно

_>Вариант a, на мой взгляд, имеет смысл применять когда серверная часть не в ходит в наш проект, к примеру это один из сервисов Google или другой сторонней организации.

Спасибо за мнение.

А>>Если расшаривать сборку, то помещена ли логика в extension или в обычные классы, сдается мне не играет существенной роли.
А>на мой взгляд, с эстетической точки зрения не очень

А>т.к. контракт данных — это именно контракт данных, а не контракт + логика

Мне казалось что разделение логики и данных имеет смысл именно в варианте a), когда структуры данных нужно протолкать через все слои приложения, а логику протолкать невозможно.
А совместное использование логики и данных тоже имеет эстетическую значимость — ведь это же инкапсуляция из ООП

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

А>Привет всем.
А>a) Клиент к службам WCF на основе WSDL может построить прокси классы, и работать с ними для транспортировки данных.
А>b) Клиент может подключить библиотеку с типами, и использовать их.
Я использую исключительно вариант (a), т.к. в таком случае доступ к сервису можно получить из чего угодно, например из сильверлайта.

A>Я использую исключительно вариант (a), т.к. в таком случае доступ к сервису можно получить из чего угодно, например из сильверлайта.
А что, на Silverlight существуют проблемы с подключением сборок? А еще SL не пробовал но звучит как-то сомнительно

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

A>>Я использую исключительно вариант (a), т.к. в таком случае доступ к сервису можно получить из чего угодно, например из сильверлайта.
А>А что, на Silverlight существуют проблемы с подключением сборок? А еще SL не пробовал но звучит как-то сомнительно
В SL можно вызвать только асинхронный вариант и генератор помогает сделать "удобный" вариант использования. Хотя с помощью Rx можно гораздо удобнее использовать стандартный Begin/End вариант

Здравствуйте, Аноним, Вы писали:
А>А что, на Silverlight существуют проблемы с подключением сборок?
Да, "обычные" сборки так просто не подключишь (из-за ограничений безопасности), у сильверлайта есть свой "тип" сборок.

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

Здравствуйте, Аноним, Вы писали:
А>Пардон, а чем отличается подключение сборок с прокси классами от сборок с обычными классами, или вы генерите прокси классы в самой SL-сборке?
Я пользуюсь стандартным "студийным" генератором, а он помещает классы в саму SL сборку.
Я понял ваш вопрос. В студии есть возможность (при установленном SL SDK) создавать 2 типа сборок — сильверлайт и обычные.

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

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

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

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

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

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

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

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

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

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

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

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

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

Во-первых, клиент — это не служба. Во-вторых, в этих цитатах идёт речь про скрытие реализации службы, мы же говорим про контракт. В-третьих, принципы и идеологии приходят и уходят, а дублирование кода остаётся.

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

_>>У варианта a есть ряд минусов:
_>>1. Вообще говоря автогенерённые код коммитить в репозиторий — не айс, если ты этот код руками, конечно, не правишь. Imho такой код должен генериться на этапе сборки.

А>Не понял в чем проблема с сохранением генерированного кода в VCS? Такой код должен генериться на этапе сборки чего — Сервиса или Клиента? А основые правки делаются в partial классах, их то коммитить можно?

В том, что если автогенерённый код не генерится при каждой сборке, то это потенциальная рассинхронизация этого кода со всем остальным кодом. А если генерится — то зачем его коммитить?

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

_>В том, что если автогенерённый код не генерится при каждой сборке, то это потенциальная рассинхронизация этого кода со всем остальным кодом. А если генерится — то зачем его коммитить?
Эм, многие применяют билд серверы, а на билд сервере внешние службы могут быть не доступны, поэтому весь код должен быть закомичен, чтобы не вызывать ошибок компиляции.

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

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

_>>В том, что если автогенерённый код не генерится при каждой сборке, то это потенциальная рассинхронизация этого кода со всем остальным кодом. А если генерится — то зачем его коммитить?
A>Эм, многие применяют билд серверы, а на билд сервере внешние службы могут быть не доступны, поэтому весь код должен быть закомичен, чтобы не вызывать ошибок компиляции.

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

Здравствуйте, anton_t, Вы писали:
_>то генерация прокси-классов, вмсесто общей сборки с контрактом — это дублирование кода и лишний геморой.
Как я указал на примере сильверлайт, использование общих сборок не всегда возможно.

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

A>Здравствуйте, anton_t, Вы писали:
_>>то генерация прокси-классов, вмсесто общей сборки с контрактом — это дублирование кода и лишний геморой.
A>Как я указал на примере сильверлайт, использование общих сборок не всегда возможно.
Мы для SL юзаем два проекта, но одни и те же файлы, правда порой вписываем #ifdef SILVERLIGHT.
А вообще подумываем о генерации части контрактов в момент компиляции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

	От:	Аноним
	Дата:	30.05.10 10:36
	Оценка:	+1

	От:	Аноним
	Дата:	30.05.10 08:57
	Оценка:

	От:	Аноним
	Дата:	30.05.10 10:49
	Оценка:

	От:	Аноним
	Дата:	30.05.10 11:00
	Оценка:

	От:	anton_t
	Дата:	30.05.10 14:19
	Оценка:

	От:	alexsoff
	Дата:	31.05.10 04:09
	Оценка:

	От:	alexsoff
	Дата:	31.05.10 04:35
	Оценка:

	От:	4izh
	Дата:	01.06.10 05:21
	Оценка:

	От:	olegkr
	Дата:	04.06.10 15:52
	Оценка: