WCF, что-то стоящее?

А чего вы тогда про язык говорите? :(

потому, что, как язык, C# довольно-таки логичен

Но я готов услышать ваше мнение по поводу нелогичности. :)

в чём нелогичность... ок, с Вашего позволения я повторюсь: я использую C# потому, что он позволяет мне не вылезать с определённого уровня абстракции, как только это правило нарушается, у меня сразу появляется вопрос - а нафига C#

> значит отжига нет, так и запишем )

Да скорее есть. Это все равно что из пушки по воробьям. Используйте просто Remoting. Он именно для этих целей.

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

ну нафиг такие технологии

> не вижу никакого криминала в том чтобы запилить свой инструмент, если это вдумчиво обосновано и в команде достаточно ресурсов

Да безусловно. :) Но мнение бытует. :)

сервисный код, которого могло бы и не быть

А вы знаете зачем этот сервисный код нужен?

я, кстати, всё делал ручками :)

И правильно. Все таки это ServiceContract.

поясню: я использую C# потому, что он позволяет мне не вылезать с определённого уровня абстракции, как только это правило нарушается, у меня сразу появляется вопрос - а нафига C#

Вы ведь должны понимать что у всякой технологии, платформы и языка есть своя область применения. Вы же на 1C не пишете игры? :) Тут то же самое. Универсальных вещей нет. У всего свои плюсы и минусы. Так что не понял я ваше высказывание. Оно не серьезное какое то.

> то есть вот у меня есть приложение, которое связывается со своим зеркальным отображением на другой машине и это тип-топ, но когда оно же начинает таким же образом общаться со своим локальным своим форком, то это уже - бида-бида, и надо спецом запиливать второй тип связи, я правильно понял?

Не понял ничего... :( Объясните доходчиво что вы имели ввиду.

Да шутка это конечно ) Не враг, понятное дело

> Потому, что, как язык, C# довольно-таки логичен

А, все понял вашу мысль, вы говорили что язык логичен и на этом фоне виден винегрет в WCF. Простите, я вас не понял изначально. :)

Ну что я могу сказать... А ничего я не буду говорить. Потому что каждый видит мир по разному. Для меня это не винегрет (WS, MSMQ, Remoting), а обертка над технологиями, потому как эти технологии и так существуют, и WCF их не принес с собой.

> то есть вот у меня есть приложение, которое связывается со своим зеркальным отображением на другой машине и это тип-топ, но когда оно же начинает таким же образом общаться со своим локальным своим форком, то это уже - бида-бида, и надо спецом запиливать второй тип связи, я правильно понял?

Не понял ничего... :( Объясните доходчиво что вы имели ввиду.

есть приложение, у него 3 инстанса: два локально на машине, один на удалённой, на кой чёрт мне запиливать дополнительный способ коммуникации между локальными инстансами?

Просто я не понял почему понадобилось запиливать второй тип связи. Если вы думаете что для перехода скажем с Remoting на SOAP необходимо будет что то допиливать, то нет. Необходимо добавить Endpoint на сервере (конфиг по сути) и сказать клиенту что теперь тебе надо туда... Или вы про что? :)

Аха, понял. Как я уже сказал в WCF достаточно допилить конфиг, добавить Endpoint.

Но я не понял чем вас в данной ситуации не удовлетворяет просто Remoting. Используйте во всех случаях его и все. WCF это все таки не для таких целей, хотя никто не мешает его так использовать.

> сервисный код, которого могло бы и не быть

А вы знаете зачем этот сервисный код нужен?

да, я даже вижу откуда его ноги растут :) но я не хочу этого видеть

> поясню: я использую C# потому, что он позволяет мне не вылезать с определённого уровня абстракции, как только это правило нарушается, у меня сразу появляется вопрос - а нафига C#

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

ну да, но я особо ничего не придумывал, посмотрел на обещания microsoft, почитал книги, решил попробовать, сделал для себя вывод, больше ничего

Вы же на 1C не пишете игры? :)

это если только для фин. отдела, серия игр - «сведи бюджет», «отчитайся за квартал» и т.д. ;)

У всего свои плюсы и минусы. Так что не понял я ваше высказывание. Оно не серьезное какое то.

то есть Вы не поняли, но всё равно решили прокомментировать - круто, чо :)

суть в том, что, используя C#, я не хочу углубляться в детали реализации различных технологий

а ещё это возможно следствие «high expectations»

Приношу свои извинения если задел в ходе обсуждения. :)

WCF это все таки не для таких целей, хотя никто не мешает его так использовать.

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

так для чего wcf хорош?

s/рекласными/рекламными/

> Вы не поняли, но всё равно решили прокомментировать - круто, чо :)

А то. :) Суть то я понял, я не понял что вы этим хотели мне сказать. Да, хорошо что вы не хотите углубляться в детали.

Просто ваше высказывание не верное. Если некая технология не покрывает ваши требования, то вам она не нужна. Но это не значит что технология не нужна никому. Именно такой вывод я сделал из вашего:

я использую C# потому, что он позволяет мне не вылезать с определённого уровня абстракции, как только это правило нарушается, у меня сразу появляется вопрос - а нафига C#

Он не нужен именно для решения вашей конкретной задачи. Но вы сказали это так, как будто C# не нужен вообще.

> так для чего wcf хорош?

В первую очередь для распределенных корпоративных приложений, Enterprise приложений, для построение SOA.

Для создания сервера приложений, независящего от протокола.

В вашем случае я бы использовал просто Remoting.

Если некая технология не покрывает ваши требования, то вам она не нужна. Но это не значит что технология не нужна никому.

погодите, причём тут нужна/не нужна, меня попросили высказать своё мнение - я высказал, какие претензии?

Именно такой вывод я сделал из вашего:

я использую C# потому, что он позволяет мне не вылезать с определённого уровня абстракции, как только это правило нарушается, у меня сразу появляется вопрос - а нафига C#

Он не нужен именно для решения вашей конкретной задачи. Но вы сказали это так, как будто C# не нужен вообще.

именно так, уверяю Вас, что C# никому не будет не нужен, если трудоёмкость написания кода на нём будет больше, чем на С++ (к примеру)

> именно так, уверяю Вас, что C# никому не будет не нужен, если трудоёмкость написания кода на нём будет больше, чем на С++ (к примеру)

Дык, вы видимо не понимаете что WCF упрощает работу, но не наоборот. :)

погодите, причём тут нужна/не нужна, меня попросили высказать своё мнение - я высказал, какие претензии?

Дело в том что у нас не холивар про .Net, а мы обсуждаем плюсы и минусы конкретной технологии: WCF. Я попробовал вас осадить просто сказав что ваши проблемы, это ваши проблемы, а не проблемы всех людей.

Я не знаю что у вас там за задачи такие, которые нельзя решить на .Net, при этом используя .Net по прямому назначению, а не онально.

> так для чего wcf хорош?

В первую очередь для распределенных корпоративных приложений

вот здесь не уверен, попробуйте, к примеру, взять два класса и синхронизировать их состояние через wcf - жуть

Enterprise приложений

тут надо указать область

для построение SOA.

Для создания сервера приложений, независящего от протокола.

тут согласен

> именно так, уверяю Вас, что C# никому не будет не нужен, если трудоёмкость написания кода на нём будет больше, чем на С++ (к примеру)

Дык, вы видимо не понимаете что WCF упрощает работу, но не наоборот. :)

я этого не увидел

Дело в том что у нас не холивар про .Net, а мы обсуждаем плюсы и минусы конкретной технологии: WCF.

да, и моё сообщение как раз относится к аспекту использования wcf

Я не знаю что у вас там за задачи такие, которые нельзя решить на .Net

всё можно, но мне не понравилась реализация

Еще бы, конечно задел. :)
Особенно в сомнении в толстости клиента... :)

Виноват. Приношу извинения еще раз. :)

Вы знаете, надоело... :(

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

Из собственного опыта могу сказать что проблем я не встречал с WCF. Более удобных технологий тоже (хотя я понимаю что не факт что их нет).

Мои задачи WCF покрывал полностью. Проблем я не встречал. Я понимаю что высказывание типа «вы просто не умеете его готовить» не являются аргументами. Но вам правда не удобно: 1. Выбирать протокол на лету 2. Использовать все возможности IDE для работы с сервисами 3. Использовать простой и понятный подход для создания самого сервиса 4. Создание прокси класса на клиенте за одну минуту 5. Полная интеграция с .Net ORM фреймворками 6. Работающая сериализация/десериализация из коробки с возможной гибкой настройкой 7. Простой деплоймент на веб сервере 8. Отличная поддержка секурности 9. Возможность создать свое собственное приложение для хостинга используя несколько строк

Если вам это не показалось удобным, то это странно. Безусловно идеальных вещей нет, но для меня в этой технологии минусов нет.

Но клиент правда тонкий. :) :)

Из собственного опыта могу сказать что проблем я не встречал с WCF. Более удобных технологий тоже (хотя я понимаю что не факт что их нет).

мне просто есть с чем сравнивать, используя Erlang, я задачи межсетевого взаимодействия решал на порядки более эффективно и красиво

Ах да, Erlang... :) :) Ну ну... :)

Сможете написать на нем быстренько RIA на erlangе? :) Нет... Знаете почему? Потому что язык не для этого. И у каждой технологии есть своя область применения. Вы сравниваете технологии из абсолютно разных областей. Это не верно.

Да, без вопросов что с памятью работать проще на C++ чем на C#. Поэтому C# не удобный...

Сможете написать на нем быстренько RIA на erlangе?

далеко не всем нужны RIA

у каждой технологии есть своя область применения.

именно, и заявленная область применения wcf оказалось куда уже, чем я ожидал

Да, без вопросов что с памятью работать проще на C++ чем на C#. Поэтому C# не удобный...

4.2

Вот тебе неймется, :) он толстый, я бы сказал даже жирный :) У него есть еще один сервер с воркфлоу у которого своя дб. Так что то, что wcf - это только малая часть того что в нем есть. Хотя с определенной точки зрения, вполне может и тонкий. :)

А че сразу 4.2? :) Ваше сравнение с эрлангом думаете лучше?

По любому тонкий. :)

Я советую вам разделать толстый и тонкий клиент так: 1. Толстый - когда клиент ломится напрямую в БД. 2. Тонкий - когда между клиентом и БД есть еще что то.

Как то слишком упрощенно. Я как бы привык разделять по месту основной бизнес логики приложения и степени независимости клиента от сервера. (ну то есть, грубо, если может делать бизнес функции без сервера(прочитал пачку данных... минут через 5 работы, обработки, агрегации данных, сохранил) - то толстый). Хранилище данных тут вторично. Иначе дойдет до того что приложение имеющая локальный конфиг(а он может быть и к примеру db) - толстый клиент.

А че сразу 4.2?

потому, что ты идиотство написал

Ваше сравнение с эрлангом думаете лучше?

конечно, тем более я их сравнивал на реальной задаче

Я советую вам разделать толстый и тонкий клиент так: 1. Толстый - когда клиент ломится напрямую в БД. 2. Тонкий - когда между клиентом и БД есть еще что то.

блин, толщина клиента определяется бизнес-логикой, а не тем как ходят пользователи

> блин, толщина клиента определяется бизнес-логикой, а не тем как ходят пользователи

Во первых не пользователи, а клиенты. Это раз.

Второе - безусловно вариант упрощенный я предложил. Просто в 99% случаях этот вариант работает.

Безусловно что толстость определяется бизнес логикой. Но при использовании WCF, у мну ну никак не поворачивается язык назвать клиента толстым.

> конечно, тем более я их сравнивал на реальной задаче

Работа с памятью не реальная задача? Почему же вы не довольны моим примером? По своему идиотству он не уступает вашему. Я бы даже сказал что ваш превосходит.

Еще пример...

Проводки между счетами легче отслеживать на 1С чем на .Net. Вы понимаете что вы совершенно не сравниваемые вещи сравниваете?

Поясню почему в 99% случаях этот вариант работает.

Просто архитекторы и разработчики понимают что им не нужна еще одна прослойка просто так. На нее будет вынесена часть логики, и скорее всего даже большая. Поэтому при использовании WCF я подразумеваю существование некого сервера приложений, который берет на себя часть работы. Иначе зачем нужен сервер приложений? Просто использование сервера приложений подразумевает то, что вы пишете тонкий клиент, иначе вы не будете использовать сервер приложений. Отсюда вывод что большинство разработчиков понимают что трехзвенная система, это в 99% случаях тонкий клиент, иначе третье звено бессмысленно.

Поэтому такой подход практически всегда дает правильную характеристику. За исключением тех систем в которых разработчики понимают что они делают.

> За исключением тех систем в которых разработчики понимают что они делают.

За исключением тех систем в которых разработчики НЕ понимают что они делают.

Есть зерно истины в этом доводе, в случае когда клиент один. Когда у тебя 2 разных клиента или разные типы дб или вообще 2 дб. Не будешь же ты тащить все в клиента? На то очень хорошо сделать доп. слой абстракции на сервере. В данном случае сервер приложений хорошо унифицирует доступ к данным, делает клиента устойчивей к изменениям дб, берет на себя некоторую рутинную работу по работе с дб.
Я не прав?

Почему же вы не довольны моим примером?

потому что Вы сказали идиотию

> блин, толщина клиента определяется бизнес-логикой, а не тем как ходят пользователи

Во первых не пользователи, а клиенты.

поясните разницу, плиз

Но при использовании WCF, у мну ну никак не поворачивается язык назвать клиента толстым.

да какая разница какой транспортный уровень используется?

> потому что Вы сказали идиотию

А вы нет? :) Вы меня умиляете. :)

> потому что Вы сказали идиотию

А вы нет? :)

Вы всё чётко подметили

> да какая разница какой транспортный уровень используется?

Слушайте, выходите из танка. Использование WCF в данном примере, это обращение к серверу приложений. И если вы мне хотите сказать что в данном случае сервер приложений не содержит логики, то я хочу спросить, зачем он тогда??? Тем более, насколько я понял он таки ее содержит. Более того у них там где то даже WWF крутится. Насколько я понял к WWF они получают доступ тоже через WCF, а WWF хоститься, где бы вы думали? Правильно, на сервере приложений. И если вы мне сейчас скажете про то что логики не достаточно на сервере при использовании WWF, то я вот прямо вот так вам в лицо скажу:

- ХА-ХА-ХА блять. Идите смотрите что такое WWF.

поясните разницу, плиз

Вы сейчас зачем дурака включаете? Вы не видите разницу между пользователем системы и понятием клиента в клиент-серверных отношениях?

> Вы всё чётко подметили

У вас великолепный танк. :)

> Когда у тебя 2 разных клиента

Дык, в этом случае просто необходимо делать тонкий клиент, зачем дублировать логику в двух клиентах на разных платформах.

разные типы дб или вообще 2 дб

Тут скорее вы правы. Но в таких случаях, чаще всего (но безусловно тот 1% имеет право на существование), на сервер приложений выносится достаточно логики что бы назвать клиента тонким.

На то очень хорошо сделать доп. слой абстракции на сервере.

А что вам мешает сделать слой абстракции на клиенте? Безусловно клиент станет объемнее. Но если вы идете в сторону толстого клиента, то вы к этому готовы. И поверьте мне, правильно спроектированная подсистема работы с данными, отлично смотрится внутри клиента и отлично унифицирует доступ к данным. И вы получите все плюсы толстого клиента.

Если вы делаете толстый клиент + сервер приложений в котором нет логики, то вы, по сути, не используете преимуществ толстого и тонкого клиента на все 100%. А берете чуток оттуда и оттуда, в итоге получается неполноценный урод.

> в итоге получается неполноценный урод

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

> Например, меняется таблица, мне не надо делать апгрейд кучи клиентских инсталяций.

Да ну? И зачем вам эта таблица? Безусловно если это сервисные вещи то на клиенте это может и не отразиться, а лишь на сервере приложений. Но если вы добавили то, что будет использоваться клиентом, то я не понимаю почему вам не придется вносить изменения в клиента...

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