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

RMI «на стероидах»

Оно еще SOAP умеет, JSON.

Многословный и тормозной монстр.
С явой сравнить не могу.

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

Кто-нибудь смотрел?

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

короче, используешь и чувствуешь что тебя надувают где-то, а где не видишь, по ощущениям очень похоже на mfc

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

//уже из примера видно что надо рисовать развесистую клюкву на вполне себе простые действия

Как-то очень уж на Spring HttpInvoker похоже

Как-то очень на Spring HttpInvoker похоже

к сожалению, с явой в этой области не сталкивался, объективно сказать ничего не могу

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

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

и да, недоделано, в том смысле, что, раз уж хотели сделать ловкую вещь, надо бы чтобы она была более прозрачна с точки зрения .net, а так проще пильнуть нормальное решение, с полным контролем что там внутри происходит

Смотрел. Ну.. стоящее. По сути - еще один слой абстракции от транспорта (MSMQ, HTTP, P2P etc - в теории )

Ящитаю, что знать необязательно, хотя, конечно, в какую .net вакансию ни харкни - везде оно «типа очень требуется причем очень глубоко знать надо».

Считайте это аналогом веб-сервисам в Java. Примерно то же самое.

Да, кстати в .NET есть зачатки P2P, но естественно как-то мутно завязаны на каких-то виндовых сервисах

>Многословный и тормозной монстр.

Если руки не очень кривые и позволяют все грамотно применить - то не такое уже и тормознутое.

Если бы да кабы...
Если делать стандартным путем, нет проблем, как бы работает, не шустро, но работает. Шаг влево, шаг вправо, все... такие костыли и дебри.

Вы знаете, это убийственная штука.

Очень легко позволяет создать на стороне сервера точку входа. После чего клиент может взаимодействовать с сервером через SOAP, MSMQ, Remoting. Отличная интеграция со студией. Разворачивается в два клика. После разворачивания меняются так называемые EndPoints которые описывают то, как можно взаимодействовать с сервером. Настраивается абсолютно все. Отличная поддержка секурности. Нормальная работа с Fault'ами. Надежно на 100%. Проблем не было.

Сейчас появилась новая штука WCF Ria Domain Services специально для взаимодействия клиента на Silverlight с сервером. Вот эта штука чуть чуть сыровата. Но уже сейчас вы можете сделать с использованием RiaServices по настоящему богатое интернет приложение. Я не знаю насколько вы знакомы с Linq, но вот RiaServices позволяет использовать Linq на стороне клиента для построения запросов к контексту EntityFramework'а (EF - обалденный ORM).

С Java знаком меньше, и поэтому аналогов я не видел.

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

Никогда не понимал таких высказываний... :(

Хочется подтверждения. И самое главное хочется понять что у вас за шаги такие влево и вправо. Может быть потребность в этих шагах вызвана вашими костылями? :)

Винегрет из технологий говорите? :) вот уж кому кому, а Java разработчику говорить про винегрет в таком тоне как то неправильно. :)

И что же за такая майкрософт-специфичная манера? :) Опять таки, не Java разработчику говорить про «натащено». :)

Еще раз хочу подчеркнуть, что нельзя говорить о технологиях, если вы про них не знаете. WCF отличная штука. Я не знаю ничего подобного в Java. Скорее всего не знаю из за неглубокого погружения в Java. Но говорить в такой манере о технологиях, о которых я не знаю, я не могу себе позволить. Чего и вам желаю. Не спортивно как то... :(

Как пример были... хм...
Самый простой - сжатие потока.
Из сложнее примеров - кеширование, когда вместо реального реквеста просто возвращался уже полученный список. Или разрулить закрытие - открытие сокетов, а то на множественных операциях были быстро исчерпаны лимиты на сокеты. Или... да многое чего было. :( Особым цинизмом был орм на дб в которой больше 300 таблиц и метровые конфигурационные xml. Или настройка кербероса со всем этим добром. Хотя уточню, что это было 2 года назад, может уже много воды утекло.

Чем больше вас читаю, тем больше хочу сказать что вы жжоте. :)

Вы случайно гриды свои не делаете? :)

Объясните что значит более прозрачную с точки зрения .net?

И как вы пришли к выводу что проще «пильнуть нормальное решение»? От этого высказывания я просто в шоке. :) :)

Сжатие давно поддерживается.

Про кэширование ничерта не понял. Какое отношение кэширование имеет к WCF? WCF - это штука которая вам позволяет передавать данные. По сути обертка над каналом передачи данных.

Про сокеты ничего не могу сказать, у меня не было таких проблем.

Про ORM на дб в которой более 300 таблиц, опять таки какое отношение это имеет к WCF? Вы имеете ввиду сериализацию? Тогда не понятно при чем тут WCF...

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

Тогда сжатия не было. Тогда, по сути, и потока не было, были только блоки, макс. размер которых определялся в xml. С этим тоже было весело.

Кеширование - если грубо, wcf делает реальный только первый реквест, последующие возвращает из кеша, с вызывающей стороны выглядит как обычный реквест.

Про ORM на дб в которой более 300 таблиц, опять таки какое отношение это имеет к WCF?

Прямое, тот орм был поверх WCF. И кстати, сериализация/десериализация передаваемых объектов это часть WCF.

Сериализация/десериализация объектов это не совсем часть WCF. Скорее это часть XML сериализации, которую поддерживают .Net типы, и есть возможность управлять сериализацией.

Про кэширование реквестов - это делает не WCF а веб сервер. WCF тут абсолютно не при чем. Копать надо было в сторону веб сервера.

Сжатие то это тоже скорее ближе к веб серверу. Но на уровне WCF уже есть возможность это указать явно.

Что вы имеете ввиду про ORM был поверх WCF? Это высказывание не верное. ORM не может быть поверх WCF. Не путайтесь. WCF - это передача данных. То как вы получаете данные к WCF не имеет никакого отношения. Можно сказать что после обращения к WCF, вы делали выборку данных с использованием ORM технологий. Но из вашего высказывания, мне начинает казаться что ваш ORM был выше по уровню чем WCF. Т.е. вы обращаетесь к ORM, который с помощью WCF получает данные.

Про сериализацию я имел ввиду то, что WCF использует заложенные в .Net механизмы сериализации/десериализации в XML, байт массив или еще что то. Самих механизмов в WCF сериализации нет. WCF использует стандартные механизмы которые реализованны в .Net.

И про таблицы... Вы же должны знать что если вы используете ORM, то это всегда дополнительные затраты на создание объектов и их последующую сериализацию/десериализацию. Возможно что в вашем случае было бы более верно (хотя не мне судить, я только предполагаю) не использовать ORM, так как у вас такая сложная реляционная модель. Либо вам надо было покопать в сторону управления сериализацией.

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

> Про кэширование реквестов - это делает не WCF а веб сервер.

Забыл сказать, толстый клиент. :) Думаю многое объяснит насчет кеширования итд. Кеширование на стороне сервера не имело смысла, ибо ограничения были на канал. Там было... забыл название, не важно, в общем канал проблемой.

Сжатие то это тоже скорее ближе к веб серверу

Двухсторонее же. Реквесты тоже сжимались.

Что вы имеете ввиду про ORM был поверх WCF?

мне начинает казаться что ваш ORM был выше по уровню чем WCF

:)

Т.е. вы обращаетесь к ORM, который с помощью WCF получает данные.

Да, так и было.

Угу, все верно, но увы, тогда архитектура и решение исходили от высокооплачевыемых архитекторов m$, менять ничего не могли. Хотя, было в определенной степени интересно по началу. :)

Я не знаю можно ли у вас метериться на форуме, но БЛЯТЬ!!!

Какой нахер толстый клиент с импользованием WCF? Вы знаете что такое толстый клиент???

Кеширование на стороне сервера не имело смысла, ибо ограничения были на канал.

Вы вообще о чем сейчас? Вы говорите что использовали кэширование на клиенте? Но блять при чем тут канал передачи данных?! Если данные закэшированы, то просто вы берете их из кэша на КЛИЕНТЕ, не обращаясь к серверу вообще. ВООБЩЕ!!!

Да, так и было.

И вы там про высокооплачиваемых архитекторов говорите ниже еще... В общем вы либо мне врете про высокооплачиваемых, либо вас обманули высокооплачиваемые архитекторы. Дело все в том, что если вы сделали обертку над прокси классами WCF на клиенте, и они сказали что это теперь !!!ORM!!! НАД (Над блять! НАД!) WCF то они абсолютно не понимают о чем говорят.

В целом, если все что вы мне сейчас сказали правда, то существует несколько вероятностей: 1. Вы АБСОЛЮТНО (подчеркиваю АБСОЛЮТНО БЛЯТЬ!) не понимаете о чем говорите. 2. Вы написали таких костылей, которых свет еще не видывал. 3. Вы правда написали свой ORM над WCF, чем изрядно меня веселите (мне жутко интересно что же вы там называете ORM над WCF).

В целом, я прошу прощения за столь эмоциональный коммент. Но вы мне вынесли мозг и изрядно повеселили. Извините если я вас обидел. Но мы поржали всем офисом. :) Спасибо вам за это. :)

Почему врага то? Мы все вместе и Java и .Net программисты решаем задачи. Я вообще .Net разработчик. Несколько холодно отношусь к Java, потому что довелось поработать с Java с не очень хорошим архитектором, который загубил проект. Из за этого, я думаю, у меня и холодное отношение к Java.

НО! Я никогда не буду считать Java врагом. Потому что это нормальная платформа которая по некоторым параметрам бьет .Net (кроссплатформенность, некоторые вкусные технологии). Но и .Net по некоторым пунктам бьет Java (простота, совместимость компонент, опять такие некоторые технологии, LINQ например).

Так что мой вас совет, знакомьтесь с WCF, знакомьтесь с .Net. Но не думайте что это враг, скорее это товарищ. :) :)

Тихо, по порядку.

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

Клиент - сервер - коммуникация между ними - WCF. Что не так?

Если данные закэшированы, то просто вы берете их из кэша на КЛИЕНТЕ, не обращаясь к серверу вообще. ВООБЩЕ!!!

Итак, смотрим ранний пост, в котором, чтобы не ломать уже готовые модули, «с вызывающей стороны выглядит как обычный реквест.»

Далее

ORM (англ. Object-relational mapping, русск. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных»

Может была использована другая технология ОРМ, но ОРМом то быть не перестало.
Серверная и клиентские части приложения имели общую интерфейсную часть, контракты wcf, которые были сгенерированы по существующей бд, но соответственно имели разную функциональность. Грубый пример, Save на клиенте городил реквест через wcf, а серверная часть выполняла Save но уже sql в дб.

Да я вообще молчу. :)

Клиент - сервер, это когда только клиент и сервер. Не в плане количества компов, а в плане звеньев. Трехзвенная система не всегда располагается на трех компах. Три звена это клиент, сервер приложений и сервер БД (чаще всего именно так). В вашем случае WCF сервисы представляет собой реализацию именно сервера приложений. Т.е. вы не стучитесь напрямую к серверу БД, а стучитесь к нему используя дополнительное звено, которое у вас и есть WCF сервис. В данном случае WCF это обертка над каналом, которая предоставляет доступ клиенту к серверу приложений. Вы удивитесь, но ваши WCF сервисы хостятся на веб сервере, который и является в данном случае сервером приложения, которое дальше ломится к БД. Три звена, вот они. :)

Да так и написано в вики:

Часто сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента.

Далее - контракты WCF это не всегда ORM объекты, но чаще всего именно ORM объекты, что бы не делать дополнительных DTO (Data Transfer Object) объектов. Далее... Вы, используя контракты передаете данные на сервис WCF. Сервис WCF десериализует эти данные. На выходе (а точнее на входе в WCF сервис) у вас объект, который и контракт WCF и ORM объект, который замаппен на БД. После этого ваша задача используя ORM и полученный с клиента объект сохранить его в БД. Получается что с помощью WCF вы обращаетесь к БД используя ORM. WCF над ORM!

Вывод: 1. WCF над ORM. Т.е. клиент ломиться к WCF сервису, который далее используя ORM ломиться к БД. 2. У вас тонкий клиент.

Итак, смотрим ранний пост, в котором, чтобы не ломать уже готовые модули, «с вызывающей стороны выглядит как обычный реквест.»

Я вас абсолютно не понимаю. Как я уже говорил, если у вас происходит кэширование на стороне сервера, то в этом виноват веб сервер. Если кэширование происходит на стороне клиента, то это виноваты вы, потому что на клиент, который представлен прокси классами WCF на клиенте, НЕ КЭШИРУЕТ данные вообще, и их закэшировали вы.

Да я вообще молчу. :)

Клиент - сервер, это когда только клиент и сервер. Не в плане количества компов, а в плане звеньев. Трехзвенная система не всегда располагается на трех компах. Три звена это клиент, сервер приложений и сервер БД (чаще всего именно так). В вашем случае WCF сервисы представляет собой реализацию именно сервера приложений. Т.е. вы не стучитесь напрямую к серверу БД, а стучитесь к нему используя дополнительное звено, которое у вас и есть WCF сервис. В данном случае WCF это обертка над каналом, которая предоставляет доступ клиенту к серверу приложений. Вы удивитесь, но ваши WCF сервисы хостятся на веб сервере, который и является в данном случае сервером приложения, которое дальше ломится к БД. Три звена, вот они. :)

Да так и написано в вики:

Часто сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента.

Далее - контракты WCF это не всегда ORM объекты, но чаще всего именно ORM объекты, что бы не делать дополнительных DTO (Data Transfer Object) объектов. Далее... Вы, используя контракты передаете данные на сервис WCF. Сервис WCF десериализует эти данные. На выходе (а точнее на входе в WCF сервис) у вас объект, который и контракт WCF и ORM объект, который замаппен на БД. После этого ваша задача используя ORM и полученный с клиента объект сохранить его в БД. Получается что с помощью WCF вы обращаетесь к БД используя ORM. WCF над ORM!

Вывод: 1. WCF над ORM. Т.е. клиент ломиться к WCF сервису, который далее используя ORM ломиться к БД. 2. У вас тонкий клиент.

Итак, смотрим ранний пост, в котором, чтобы не ломать уже готовые модули, «с вызывающей стороны выглядит как обычный реквест.»

Я вас абсолютно не понимаю. Как я уже говорил, если у вас происходит кэширование на стороне сервера, то в этом виноват веб сервер. Если кэширование происходит на стороне клиента, то это виноваты вы, потому что на клиент, который представлен прокси классами WCF на клиенте, НЕ КЭШИРУЕТ данные вообще, и их закэшировали вы.

> Три звена, вот они. :)
Ну хорошо, пусть так. Если до мелочей. :)

2. У вас тонкий клиент.

Не путай меня, я уже 24 часа за компом. :) Большая часть бизнес логики была на клиенте, включая агрегацию данных. Сервер приложений - прослойка wcf -> db. За исключением некоторого контроля данных. Какой уже тонкий клиент то.

Получается что с помощью WCF вы обращаетесь к БД используя ORM.

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

то это виноваты вы, потому что на клиент, который представлен прокси классами WCF на клиенте, НЕ КЭШИРУЕТ данные вообще, и их закэшировали вы.

Вот тут я не понял, ServiceContract уже научился кэшировать данные? Или это противоречит логике?

Кароче, вывод, я нихрена не умею объяснять.

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

не вся, а только часть её, в листинге «Hosting the service, implementing the server»

и здесь, как раз основной весёлой клюквы нет, это просто минимум, который будет работать

Если вы используете веб сервер, то эта клюква не нужна.

ога, вот я делаю standalone application, и теперь, Вы говорите, чтобы оно заработало мне надо поднять IIS (не просто какой-то там веб-сервер, заметьте)? да, это отжиг

Винегрет из технологий говорите? :)

да, и сособенно сильно это проступает на фоне логичности самого языка

вот уж кому кому, а Java разработчику говорить про винегрет в таком тоне как то неправильно. :)

ну, наверное, но я не Java-разработчик, если что :)

Вы случайно гриды свои не делаете? :)

не, мне не надо, но если бы было надо - сделал бы

Объясните что значит более прозрачную с точки зрения .net?

более высокоуровневую, одни пляски с генерацией контракта внешними костылями уже чего стоят

И как вы пришли к выводу что проще «пильнуть нормальное решение»?

легко: посмотрел на сопли, которые получились в итоговом приложении

а ещё посмотрел как обработчики событий легко и просто пишутся, в случае, чуть сложнее hello world

а ещё посмотрел что нужно сделать, чтобы поднять 3-4 сервера рядом

да нафига оно вообще нужно, если к нему даже сериализацию через трах прикручивать надо? если так, то я и без мелкомягких всё сделаю

контракты WCF это не всегда ORM объекты, но чаще всего именно ORM объекты

контракты - это Вам не объекты, это, если хотите, интерфейсы

> Ну хорошо, пусть так. Если до мелочей. :)

Это не мелочи, это важный принцип построения систем.

Какой уже тонкий клиент то.

Вот такой вот хреновый. Но это тонкий клиент, и толстым назвать его нельзя.

Вот тут я не понял, ServiceContract уже научился кэшировать данные? Или это противоречит логике?

Я вас тоже сейчас не понял, при чем тут ServiceContract?

Кстати, с этим же ормом еще и локальный «сервер приложений» работал, без всф, то есть с логического представления вцф один из возможных транспортов

Вот этот «сервер приложений» гораздо более похож на толстый клиент чем ваш клиент работающий через WCF.

Верх, низ, над... под... пофиг.

Мне нет. От этих «Верх, низ, над... под...» зависит то как меня понимают мои товарищи. И в вашем случае, когда вы говорите «ORM над WCF», не понятно вообще ничего. Уж извините... :(

В целом, еще раз возвращаясь к теме топика: 1. Не встречал ни разу потребности в костылях при работе с WCF 2. Отличная интеграция с IDE 3. Легкое конфигурирование 4. Поддержка секурности 5. Гибкость и легкое расширение 6. Элементарный хостинг

Как бе плоха та оценка технологии в которой нет минусов, но вся проблема в том, что мое знакомство с остальными технологиями выявляет то, что минусов нет. Серьезно. :)

Пример: Веб сервисы на Java. Использовали мы Jax-WS. Реализация от SUN, если я не ошибаюсь. И пришлось таскать через веб сервисы объекты от IBM (производственная необходимость, было дорого переписывать серверную часть), которые хранили в себе результаты выборки из БД (к сожалению название типов уже не помню). В результате объекты от IBM не пролазили через сервисы SUN, потому что в типах не было каких то атрибутов необходимых для нормальной работы Jax-WS и поддержки SOAP (имеется ввиду XML сериализция и создание WSDL файла). Пришлось использовать байт сериализацию (благо клиент был тоже на Java), полностью этим убив все преимущества SOAP.

На .Net вы такого не встретите с WCF Какие бы внешние типы вы не использовали, а все потому что в WCF используются реализованные в самой платформе .Net механизмы сериализации.

Безусловно это Interaface, который требует реализации как на стороне клиента так и на стороне сервера.

Не забывайте что Interface описывает интерфейс экземпляра типа.

Вообще не понял чего вы этим хотели сказать. :( Ваша колкость не удалась. :)

> ога, вот я делаю standalone application, и теперь, Вы говорите, чтобы оно заработало мне надо поднять IIS (не просто какой-то там веб-сервер, заметьте)? да, это отжиг

Это отжиг, если вы используете WCF в standalone application.

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

:) Вы считаете что .Net это язык?

ну, наверное, но я не Java-разработчик, если что :)

Ой, простите. :)

> не, мне не надо, но если бы было надо - сделал бы Не вздумайте! Бытует мнение что это первый признак провального проекта. :)

более высокоуровневую, одни пляски с генерацией контракта внешними костылями уже чего стоят

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

посмотрел на сопли, которые получились в итоговом приложении

Что вы подразумеваете под соплями? :)

а ещё посмотрел как обработчики событий легко и просто пишутся, в случае, чуть сложнее hello world

Кхм... Обработчики событий сложно написать? Надеюсь вы имеете ввиду Async запросы?

а ещё посмотрел что нужно сделать, чтобы поднять 3-4 сервера рядом

И что же? Просветите мну. :)

да нафига оно вообще нужно, если к нему даже сериализацию через трах прикручивать надо?

Да не надо прикручивать ничего. :) Все работает из коробки. :) Или вы про что? Опять таки, примеры в студию. :)

Безусловно это Interaface, который требует реализации как на стороне клиента так и на стороне сервера.

Не забывайте что Interface описывает интерфейс экземпляра типа.

я-то это знаю, как и то, что из интерфейса Вы объект не создадите

Вообще не понял чего вы этим хотели сказать. :( Ваша колкость не удалась. :)

это не колкость, я просто уточнил

> ога, вот я делаю standalone application, и теперь, Вы говорите, чтобы оно заработало мне надо поднять IIS (не просто какой-то там веб-сервер, заметьте)? да, это отжиг

Это отжиг, если вы используете WCF в standalone application.

во-первых, почему же отжиг, если wcf так хорош, то и для IPC небось сгодится, или нет?

во-вторых, говоря standalone я имел в виду, в первую очередь - «не web-приложения», например n приложений на k машинах, которые должны общаться друг с другом

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

:) Вы считаете что .Net это язык?

Вы где-то об этом у меня прочитали, или сами напридумывали?

> во-первых, почему же отжиг, если wcf так хорош, то и для IPC небось сгодится, или нет?

Я бы тут использовал просто Remoting без WCF. Но WCF тоже мона, он работает с Remoting и IIS не понадобится.

> Вы где-то об этом у меня прочитали, или сами напридумывали?

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

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

> Вот такой вот хреновый.
Какой есть, по крайней мере в той толстой доке которую мне давали, там был толстый.

Мне нет.

Ты не понял, мне уже поф. :) Я понял, что ты имел ввиду и что тебя рассмешило. :) Сорри, иногда, после пары лет перерыва очень тяжело объяснить и вспомнить те слова...

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

> не, мне не надо, но если бы было надо - сделал бы

Не вздумайте! Бытует мнение что это первый признак провального проекта. :)

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

> более высокоуровневую, одни пляски с генерацией контракта внешними костылями уже чего стоят

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

microsoft-way

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

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

Что вы подразумеваете под соплями? :)

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

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

> во-первых, почему же отжиг, если wcf так хорош, то и для IPC небось сгодится, или нет?

Я бы тут использовал просто Remoting без WCF. Но WCF тоже мона, он работает с Remoting и IIS не понадобится.

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

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

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