Вот мое решение проблемы:
Я бы создал слой над сервисом, который и вычисляет это поле, и который используют эти два клиента. Прокси классы в этом слое расширил бы новым свойством (partial).

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

А>Вот мое решение проблемы:
А>Я бы создал слой над сервисом, который и вычисляет это поле, и который используют эти два клиента. Прокси классы в этом слое расширил бы новым свойством (partial).

На пустом месте усложнили. Зачем?

L>На пустом месте усложнили. Зачем?

Почему усложнил? Введением нового слоя? Мне кажется наличие такого слоя не избежать, во всяком случае, я бы ввел его изначально
Или тем что отделил данные представления от данных? Разве это не естественно

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

L>>На пустом месте усложнили. Зачем?

А>Почему усложнил? Введением нового слоя? Мне кажется наличие такого слоя не избежать, во всяком случае, я бы ввел его изначально

У тебя прокси где будут? Это будет отдельная сборка или как?

А>Или тем что отделил данные представления от данных? Разве это не естественно

А они были смешаны?

L>У тебя прокси где будут? Это будет отдельная сборка или как?
Да это будет отдельная сборка

L>А они были смешаны?
Ну обычно, всякие вычисляемые DisplayName — это данные представления, сервис может и без них обходиться.
Но допустим, вычисляемое поле это поле со сложными вичислениями требущими сложную логику, дерганием других сервисов. Тогда в этом случае логика, проводящая вычисления находится на сервере. Когда клинет меняет значения, он обращается к сервису, с просьбой вычислить эти новые значения и задачей сервиса является эти вычисления. Если же ты шаришь эту логику в библиотеке, какой смысл в использовании сервиса?

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

L>>У тебя прокси где будут? Это будет отдельная сборка или как?
А>Да это будет отдельная сборка

Вот этим и усложняешь.

L>>А они были смешаны?
А>Ну обычно, всякие вычисляемые DisplayName — это данные представления, сервис может и без них обходиться.

И из того, что сервер может обходится без них, ты решил, что DisplayName — в представлении? Почему этот код не может быть во внешней вспомогательной сборке, никак не завязанной ни на сервис, ни на представление?

L>И из того, что сервер может обходится без них, ты решил, что DisplayName — в представлении? Почему этот код не может быть во внешней вспомогательной сборке, никак не завязанной ни на сервис, ни на представление?

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

Это мои представления об идеальной системе

L>Programming WCF Services (Second Edition)+ sources
Большое спасибо.

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

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

_>>Допустим мы запретили использовать общие сборки на сервере и на клиенте. Что в этом случае делать, например, с валидацией? Реализовывать отдельно на сервере и на клиенте?

H>Сильно зависит от валидации. Клиент не может в принципе выполнить туже валидацию, что и сервер, потому что данные, которыми он обладает, уже потенциально устарели.
H>Если же, например, валидируется заполнено поле почтового адреса в принципе или нет, то на сервере такая валидация может случится на уровне данных, закопанных в сборке реализации. Шарить ее я бы не стал. А если клиент установлен на 100 компах, то ролаут изменений общей сборки выливается в боль для админов (и не только для них).

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

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

_>>>Допустим мы запретили использовать общие сборки на сервере и на клиенте. Что в этом случае делать, например, с валидацией? Реализовывать отдельно на сервере и на клиенте?

H>>Сильно зависит от валидации. Клиент не может в принципе выполнить туже валидацию, что и сервер, потому что данные, которыми он обладает, уже потенциально устарели.
H>>Если же, например, валидируется заполнено поле почтового адреса в принципе или нет, то на сервере такая валидация может случится на уровне данных, закопанных в сборке реализации. Шарить ее я бы не стал. А если клиент установлен на 100 компах, то ролаут изменений общей сборки выливается в боль для админов (и не только для них).

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

Я об этом и говорил. И для этого не обязательно что-то шарить общее. Теже регэкспы/правила валидации на клиенте можно получить с сервера и кэшить какое-то время.