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

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

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

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

В таком случае
а) решим проблемы обсуждаемые в соседих ветках,
b) построим приложение с более чистой архитектурой (ИМХО)

но куда смещать логику?
1) На клиента. Плюсы и минусы:
— безмозглый сервис наверное имеет смысл (ИМХО) только если читать/(со)хранить данные
— определенно увеличивается трафик, логика клиента будет чаще обращатся к Service (ИМХО)
+ Сервис будет менее статусным (ИМХО), весь статус будет обрабатываться на клиенте
— Если логика пишится для клиента на .NET, тогда верхний слой сидит на игле .NET, так как эта библиотека .NET
+ Проще обрабатывать ситуации, когда сервис недоступен (ИМХО), выполнять ассинхронные запросы
+ Тогда (ИМХО) контракт будет не так часто меняться, отсюда меньше проблем с обновлением клиентов
2) На сервис. Плюсы и минусы:
+ уменьшается трафик
— Наверняка на строне сервиса придется хранить статус, который усложняет асинхронный вызов служб
— если служба грохается (например timeout) проблемы с восстановлением статуса

Что вы думаете по этому поводу?

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

А>Что вы думаете по этому поводу?

Думаю, что все перечисленное не имеет никакого отношения к вопросу использования сборок/генерации проксей.

L>Думаю, что все перечисленное не имеет никакого отношения к вопросу использования сборок/генерации проксей.

Ну как же, уже идет дискуссия, что понимается под методами/логикой и где она должна храниться

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

L>>Думаю, что все перечисленное не имеет никакого отношения к вопросу использования сборок/генерации проксей.

А>Ну как же, уже идет дискуссия, что понимается под методами/логикой и где она должна храниться

Да ну? Где?

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

А>Что вы думаете по этому поводу?

Думаю бред какой-то написан.

Вообще-то этот вопрос лишь НАВЕЯН соседними ветками, поэтому он выдлелен в новую тему, а не продолжает дискуссию в тех темах.

L>Да ну? Где?
Вот собственно:

S>Вопрос для чайников
Спасибо за комплимент.
S>Вот только в классах есть не только свойства, но и методы. И вот вопрос, что нужно сделать чтоб передавались эти методы?
Передать методы? Это как? Отбросьте в торону wcf. Представьте, что вам нужно передать экземпляр класса с методами в некую функцию в том же самом процессе. Что в этом случае означает передать методы?
Как вы планируете на wcf-клиенте вызывать переданные методы, если бы это было возможно?
----------
S>Передать методы? Это как? Отбросьте в торону wcf. Представьте, что вам нужно передать экземпляр класса с методами в некую функцию в том же самом процессе. Что в этом случае означает передать методы?
S>Как вы планируете на wcf-клиенте вызывать переданные методы, если бы это было возможно?

Например у меня есть класс А, в котором к переопределен метод ToString(). На wcf-клиенте, в котором есть только референс на wcf-сервис я получаю объект класса А, вызываю ToString() и получаю результат переопределенного метода.
------------
S>Например у меня есть класс А, в котором к переопределен метод ToString(). На wcf-клиенте, в котором есть только референс на wcf-сервис я получаю объект класса А, вызываю ToString() и получаю результат переопределенного метода.

Так. Вы хотите, чтобы на клиенте была логика метода ToString класса A. Вопрос, где должна храниться логика этого метода? Чтобы выполнить некую логику, она должна быть скомпилирована и загружена в память. Кроме того, просто логика одного метода или класса не может быть загружена в память. Нужно, чтобы в памят была загружена сборка, содержащая этот класс. Есть ли смысл передавать по сервису сборку на клиента, если ее можно просто на клиенте добавить в референсы?

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

А>Вообще-то этот вопрос лишь НАВЕЯН соседними ветками, поэтому он выдлелен в новую тему, а не продолжает дискуссию в тех темах.

Он не может быть навеян соседними веткати, т.к. никакой связи между теми ветками и этой — нет.

L>>Да ну? Где?
А>Вот собственно:

Ты просто не понял, что тебе пытаются втолковать.

G>Думаю бред какой-то написан.
Хорошо что я аноним
кстати, в каких местах это особенно проявлено?

L>Ты просто не понял, что тебе пытаются втолковать.

Жалко, мое самомнение страдает.

Я думаю что я понял это имено так, как понял. Товарищ Spiceman пытается убедить Spinne, что подключение сборок предпочтительно для испльзования совсестной логики. Я же говорю о том, что такого желания не должно возникать, что приложение должно быть так спроектированно, что ни о каких совместных методах не было и речи

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

G>>Думаю бред какой-то написан.
А>Хорошо что я аноним
А>кстати, в каких местах это особенно проявлено?

Правильный ответ на твой вопрос уже дали. Если ты хочешь передавать объект класса X с сервера на клиент и вызывать на клиенте методы класса X, то ты должен добавить в референсы клиента сборку класса X.
Все дальнейшее рассуждение об "архитектуре" и прочей фигне является плодом твоего непонимания принципов и работы .NET, WCF и других трехбуквенных сочетаний.

G>Правильный ответ на твой вопрос уже дали. Если ты хочешь передавать объект класса X с сервера на клиент и вызывать на клиенте методы класса X, то ты должен добавить в референсы клиента сборку класса X.

Это понятно, и почему это так я это прекрасно понимаю.

G>Все дальнейшее рассуждение об "архитектуре" и прочей фигне является плодом твоего непонимания принципов и работы .NET, WCF и других трехбуквенных сочетаний.

Можно поконкретней, я не совсем понимаю о каких именно принципах идет речь

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

А>Жалко, мое самомнение страдает.

А>Я думаю что я понял это имено так, как понял. Товарищ Spiceman пытается убедить Spinne, что подключение сборок предпочтительно для испльзования совсестной логики.

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

А>Я же говорю о том, что такого желания не должно возникать, что приложение должно быть так спроектированно, что ни о каких совместных методах не было и речи

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

L>Ты не от того отталкиваешься. Генерация проксей — неестественный способ, он нужен только для случая интеграции разнородных систем. Если вы сами целиком и полностью разработываете сервис, и все клиенты — на .Net-е, то нет никакого стимула использовать генеренные прокси. Вместо этого гораздо удобнее и естественнее использовть общие сборки.

Насчет удобнее согласен, на счет естественней, круто сомневаюсь (я на самом деле уважаю твое Lloyd мнение). Мне кажется, здесь надо отталкиваться от принципов создания SOA, и как вообще проектируются эти компоненты. У меня самого опыта создания таких систем нет, и потому я высказывают свое ламерское мнение. Есть только желание разобраться

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

Мне кажется, что служба должна быть так спроектированна, что поле DisplayName, должно вычисляться в одном месте (или клинет, или сервис)

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

А>Мне кажется, что служба должна быть так спроектированна, что поле DisplayName, должно вычисляться в одном месте (или клинет, или сервис)

Т.к. это поле вычислимое — то оно зависит от значения других полей, которые могут быть поменяны клиентом. Поэтому точно сервер не подходит.
Остается толкь клиент. Теперь обращаем внимание на то, что 2 клиента. Если клиент работает с проксей, то все, приплыли, придется копипастить реализацию DisplayName-а. Если отдельная сборка для контракта — то все в шоколоде.

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

L>>Ты не от того отталкиваешься. Генерация проксей — неестественный способ, он нужен только для случая интеграции разнородных систем. Если вы сами целиком и полностью разработываете сервис, и все клиенты — на .Net-е, то нет никакого стимула использовать генеренные прокси. Вместо этого гораздо удобнее и естественнее использовть общие сборки.

А>Насчет удобнее согласен, на счет естественней, круто сомневаюсь (я на самом деле уважаю твое Lloyd мнение). Мне кажется, здесь надо отталкиваться от принципов создания SOA, и как вообще проектируются эти компоненты. У меня самого опыта создания таких систем нет, и потому я высказывают свое ламерское мнение. Есть только желание разобраться

1. Если какой-то принцип противоречит здравому смыслу, то это проблемы принципа, а не здравого смысла.
2. Ещё ни разу не встречал, что бы в книгах или статьях по SOA писали: "запрещается использовать общие сборки на сервисе и на клиенте".

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

А>Мне кажется, что служба должна быть так спроектированна, что поле DisplayName, должно вычисляться в одном месте (или клинет, или сервис)

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

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

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

А>>Мне кажется, что служба должна быть так спроектированна, что поле DisplayName, должно вычисляться в одном месте (или клинет, или сервис)

L>Т.к. это поле вычислимое — то оно зависит от значения других полей, которые могут быть поменяны клиентом. Поэтому точно сервер не подходит.
L>Остается толкь клиент. Теперь обращаем внимание на то, что 2 клиента. Если клиент работает с проксей, то все, приплыли, придется копипастить реализацию DisplayName-а. Если отдельная сборка для контракта — то все в шоколоде.

Уточни пожалуйста, зачем это замечание что 2 клиента. Имеешь ввиду что изменения значений одним клиентом должен видет второй клиент? Я не понял этого замечания

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

А>Уточни пожалуйста, зачем это замечание что 2 клиента. Имеешь ввиду что изменения значений одним клиентом должен видет второй клиент? Я не понял этого замечания

Два клиента — не 2 инсталляции оной программы, а две разные программы. Напрмер, веб-морда и десктопное приложение.

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

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

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

_>1. Если какой-то принцип противоречит здравому смыслу, то это проблемы принципа, а не здравого смысла.
_>2. Ещё ни разу не встречал, что бы в книгах или статьях по SOA писали: "запрещается использовать общие сборки на сервисе и на клиенте".

Я уже кучу материала пересмотрел, нигде не могу найти примеры использования, что бы для на клиенте испльзовались общие сборки используемые в контракте. Только прокси. Кстати, хотелось бы поиметь хваленную книгу Juval Löwy, Programming WCF Services в электронном виде ; клянусь позже куплю, прям так и хочетсчя подсмотреть что автор по всем этом делам думает.

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

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

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

А>Я уже кучу материала пересмотрел, нигде не могу найти примеры использования, что бы для на клиенте испльзовались общие сборки используемые в контракте. Только прокси. Кстати, хотелось бы поиметь хваленную книгу Juval Löwy, Programming WCF Services в электронном виде ; клянусь позже куплю, прям так и хочетсчя подсмотреть что автор по всем этом делам думает.

Programming WCF Services (Second Edition)+ sources

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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