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

S>Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех". Я специально прочитал текст дважды и не нашёл ни одного более-менее внятного тезиса, только "все вокруг — нубы, а я — д'Артатьян!". Что тут обсуждать —

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

Про динамику — тоже доля истины есть. Но вывод там должен быть не в плане динамики (сам автор не понял, что именно он понял), а в некоей неразборчивости в ср-вах у профессионала и индиферентности к т.н. "подходам". Т.е. после понимания, что все эти ср-ва и "подходы" сами по себе не так важны, а лишь интересны как инструменты для достижения цели... и тогда много других инструментов оказываются вполне подходящими. В т.ч. динамические языки для большого класса задач. А у новичков зачастую исходные цели обильно приправляются сугубо собственными, напр: поюзать такую-то билиотеку/паттерн/язык, попробовать "на вкус" то-то и то-то.

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

VD>Здравствуйте, Ведмедь, Вы писали:

В>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.

VD>О, как? А написание тестов — это не написание кода?

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

VD>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.

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

Мой пример тоже далеко не общий, но твое заблуждение очень даже обще. Программист редко (почти никогда) имеет дело со спецификациями, достаточными для "тупого" кодирования. Почти всегда ставятся относительно высокоуровневые задачи из некоей предметной области, будь-то автоматизация бизнеса, или окучивание неких сугубо технических подробностей. Поэтому почти всегда сначала надо строить модель из предметной области, и уточнять требования, по мере того, как модель становится все более детальной, а после их уточнения уже выходить на окончательный список требуемой функциональности + ограничений. А уточнение требований — это процесс, при котором одно высокоуровневое требование порождает несколько (иногда десятки) зависимых требований. А уж сколько подробностей генерят сочетания неких требований, на первый взгляд противоречивых... но это уже как повезет.


VD>С тестами же все как с обычным кода. Чем гибче язык, тем лучше на нем можно автоматизировать тестирование.

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

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


VD>Ну, и на тесты не должно уходить более 20% времени разработки.

От предметной области зависит. Такой низкий % характерен для сугубо вычислительных задач, где синтетика максимально близка к самой предметной области, т.е. подготовка/разработка автоматического тестирования (любого уровня) дается относительно дешево. Но взять хотя бы твою любимую область — компиляцию. Тут объем трудоемкости для разработки всего, связанного с тестированием (в основном, исходных данных, т.е. кода для компиляции) по трудоемкости может многократно превышать затраты на кодирование и отладку всего, что покрываемо юнит-тестами. Иначе эту работу вместо тебя будут делать юзвери, а это допустимо разве что для опен-сорса.


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

Нет, конечно. Это такие же важные этапы. Непроизводительные расходы — это борьба с неточными спецификациями. Или клиентами, их генерящими. Сокращать или нет — зависит от модели бизнеса. Если вполне допустимо сваливать на плечи юзверов часть трудоемкости по верификации программы.. то почему бы и нет. А если сие недопустимо, то сокращение твоих "непроизводительных расходов" может привести к сокращению или потере собственно бизнеса.

В>>2. Формализованные и понятные требования. ТОже без единой строчки кода

VD>Вот это уже дело программистов. И то скорее, в некоторых случаях, ее выполняют выделенные еденицы вроде архиеткров и т.п.

Обычно очень поверхностно. И это правильно, если разобраться. Должна оставаться некая свобода действий для того, кто будет всё это реализовывать, т.е. кто будет лучше всех знать подробности конкретного участка.


VD>Опять же, для формилизации прототипирование будет не лишним. Так что строчки кода уже могли бы и появиться.

От предметной области зависит. Если предметная область достаточно исследована "кем-то еще", будь то математические алгоритмы обработки сигналов или четко описанные спецификации неких протоколов, то прототипирование и даром не надо. Прототипирование вообще зачастую нужно более для уточнения требуемых для "неизведанной области" ресурсов (если никто не имел достаточного опыта для оценки трудоемкости до этого), чем для архитектуры, бо любые подробности обычно спрятать за интерфейсами/протоколами без проблем.

Хотя, если весь проект такой, что никто никогда и близко с ничем подобным не сталкивался, то тут требуется "прототипирование всего". Но такие проекты обычно никто и не начинает сразу на 100%. Берется 5-10% человекоресурсов для разработки прототипа, и только потом принимается решение, быть ли проекту вообще или ну его нафик. Т.е. к моменту начала основных работ опять же, прототипирования практически не будет.


VD>Это у вас тоже программисты делаю? Не, я согласен, тут нужно создать инсталлятор (если пользователей много), проестироват его, написать инструкцию, если надо. Но это не задача программиста. Или задача специально выделенного программиста-прикладника.

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

VD>А на этапе проектирования вы что делали? Или у вас получившееся решение отличается от исходного?

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


VD>Ну, да опять же. По уму тут нужно привлекать техрайтеров. Или опять получается использование программиста не по назначению. Ну, да по бедности и такое бывает. Но раз так, то не надо считать, что это часть разработки. Это часть работы которую человек вынужден совмещать с трудом программиста.

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


В>>4. Теперь все это надо СДАТЬ

VD>О, как? А это тоже программист делает?

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


VD>Ребята, да у вас какая-то каша получается. Вы смешиваете несколько видов деятельности и на этом основании говорите, что разработка не является основным видом деятельности. Но это всего лишь разные виды деятельности. В конторах где есть более 4 человек она должна выполнятся разными людьми.

Популярное заблуждение. Больше 40-ка не хочешь?
Для 4 человек можно разве что тестера выделить. Остальные будут разработчиками, а все остальные роли будут поделены м/у собой (и тестером в т.ч.), т.е. будет совмещение. Это от того, что очень сложно делить информационный объем сугубо на горизонтальные пласты. При таком кол-ве людей каждый должен будет знать всё на своем уровне. Проще, начиная с какого-то уровня делить вертикально, т.е. по предметным областям. Вот и получается, что программировать будут все. Пусть даже кто-то и лидер, это не меняет ничего принципиально.

VD>А программист должен:
VD>1. Проектировать.
VD>2. Кодировать.
VD>3. Писать и прогонять тесты.
VD>4. Отлаживать и исправлять ошибки.

Абсолютно правильно. Но проектирование без требований не бывает. А требования необходимо анализировать, уточнять, развивать. Выше уже высказывался. М/у требованиями и функционалом должно стоять соответствие 1:1 на любом уровне разработки, т.е. без работы над требованиями обычно никуда. А теперь учитываем, что это рисунок лишь одной итерации, т.е. в процессе нормальной разработки это всё приходится делать по кругу.


VD>Все это процессы непосредственно связанные с кодом. В любой из фаз, программист пишет, читает или думает о коде.

1. О требованиях и модели, позволяющей реализовать эти требования
2. Об интерфейсах, зависимостях, требованиях и модели
3. О требованиях + наводимых перекрестных сценеариях + граничные случаи + инварианты и т.д.
4. Когда ошибки по невнимательности, то думает о коде. Но эту тривиальность даже обсуждать лень. Все гораздо интересней, когда ошибки связаны с неполным/неверным представлением о предметной области или порождены багами в требованиях/спецификациях. Тогда приходится думать вовсе не понятиями кода.

Не знаю, когда там программист думает о коде. Я зычастую написал и забыл. У меня их сотни строк ежедневно, что о них думать? Но вот зависимости, высокоуровневые интерфейсы/протоколы, требования, выбранная модель их реализоции, особенности предметной области — это надо в памяти держать постоянно, чтобы назавтра иметь возможность накатать очередную сотню-другую строк... а сам код я обычно не помню. Да он и пишется на автомате и мозжечком больше, когда "общую картинку" в голове построишь. Как в той сказке: одну беру, на другую смотрю, третья мерещится... примерно так.


В>>И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух:
В>>1. Слишком мало времени уделяется другим фазам

VD>Ага. Заключению договров и внедрению .

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


В>>(скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).

VD>И что, много багов не относится к коду? Халтурно писали код, получите море отладки. Уделяйте больше времени и внимания качеству написания кода, и получите меньше отладки. А лучше повышайте уровень кода, и уровень его контроля.

Удивительно, что это написал человек, работающий над компилятором. Сколько уже было исправлений, которые порождены исключительно разночтениями или даже исправлениями спецификаций языка? Не счесть. Как бы внимательно не писался код, этого было не избежать. Это же та самая стадия тестирования. Которая, правда, выполнялась сообществом.


VD>Ну, да если плевать на код и не считать его главным, а потом обосновывать баги тем, что код — это не главное, то конечно можно и до такого абсурда договориться.

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

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

I>>А реально soap тот же заметить просто нечем...

IT>Можно подумать до soap жизни на земле не было.

При чем здесь жизнь до soap ?

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

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

VD>Никому не нужен WCF. Нужен SOAP иди REST. А — это всего лишь библиотека упрощающая их реализацию.

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

>И если в случае SOAP в WCF есть смысл, то в случае REST в WCF смысла нет. REST реализуется на коленке за два дня программстом среднего уровня.

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

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

VD>>Никому не нужен WCF. Нужен SOAP иди REST. А — это всего лишь библиотека упрощающая их реализацию.

I>Это не библиотека, это уже технология, при чем ориентированая не на бизнес а на инфраструктуру. Следовательно она должна быть одна единственная.

В программировании есть более четкие понятия:
1. Алгоритм — точный набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное время.
2. Библиотека — набор подпрограмм или классов, используемых для разработки ПО.
3. Протокол (передачи данных) — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами.

Так вот WCF — это именно библиотека. Ее замена не меняет ровным счетом ничего. Объясняется это очень просто — эта библиотека использует в качестве протокола стандарты. Раньше это был только SOAP. Теперь вот, оказывается, появился еще REST. Но оба протокола стандартизированы и, стало быть, проблем с заменой библиотек нет.

А "Технология" — это общие, не несущие ничего конкретного, слова.

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

REST — это очень простой протокол. По сути он состоит из роутинга и сериализации данных. Если не брать стриминг (который для организации RPC не нужен), то реализовывать там особо и не чего.

Скажу больше. Если RESTful, который (как оказалось) теперь входит в состав WCF, позволяет без лишнего гимора (присущего WCF-у при работе с SOAP) реализовывать REST и обеспечивает хорошую производительность, то его точно так же можно использовать для реализации публичных сервисов. Но полагаться, при этом, нужно именно на протокол (т.е. на REST), а не WCF и великий Майкрософт.

I>Потому, скажем, если "программист среднего уровня" это "десять+ лет опыта в реализации протоколов в т.ч. RPC и тд." то я абсолютно согласен

Какой-то набор слов. Но опыт реализации RPC — это точно положительный опыт. По крайней мере человек должен знает что такое протокол, а что библиотека. И должен понимать, что библиотека не обязана быть одной единственной. Если можно взять (или написать) существенно более простую библиотеку обеспечивающую лучшие характеристики, то лучше так и поступить. Как минимум не будешь привязан к конкретной версии фрэймворка.

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

VD>В программировании есть более четкие понятия:

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

VD>Так вот WCF — это именно библиотека. Ее замена не меняет ровным счетом ничего. Объясняется это очень просто — эта библиотека использует в качестве протокола стандарты. Раньше это был только SOAP. Теперь вот, оказывается, появился еще REST. Но оба протокола стандартизированы и, стало быть, проблем с заменой библиотек нет.

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

VD>А "Технология" — это общие, не несущие ничего конкретного, слова.

Для тебя — да. Ты мог бы и не повторяться.

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

VD>REST — это очень простой протокол. По сути он состоит из роутинга и сериализации данных. Если не брать стриминг (который для организации RPC не нужен), то реализовывать там особо и не чего.

Наверное это основная причина, по которой самопальные реализации REST есть просто УГ

I>>Потому, скажем, если "программист среднего уровня" это "десять+ лет опыта в реализации протоколов в т.ч. RPC и тд." то я абсолютно согласен

VD>Какой-то набор слов. Но опыт реализации RPC — это точно положительный опыт. По крайней мере человек должен знает что такое протокол, а что библиотека. И должен понимать, что библиотека не обязана быть одной единственной. Если можно взять (или написать) существенно более простую библиотеку обеспечивающую лучшие характеристики, то лучше так и поступить. Как минимум не будешь привязан к конкретной версии фрэймворка.

Заюзав WCF и столкнувшись с необходимостью накинуть админку например на сервелате или требование реализовать мобайл клиент на этом сервелате, окажется что нет никаких проблем с этим — у микрософта все продумано. А если вдруг ОРМ придется заюзать, то внезапно оказывается что EF отлично вписывается в эту схему. А когда понадобится воркфлоу, опаньки, снова всё отлично вписывается , а у тебя любое изменение требований это геморрой с написанием своих "библиотек", эдакий возврат в девяностые но на дотнете
В любом более менее серьёзном проекте столько вещей, что выбор wcf-не-wcf уже не стоит, т.к. это выбор между n готовых решений или n**2 самопальных велосипедов.

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

I>>>А реально soap тот же заметить просто нечем...
IT>>Можно подумать до soap жизни на земле не было.
I>При чем здесь жизнь до soap ?

При том, что "реально soap тот же заменить просто нечем".

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

I>Заюзав WCF и столкнувшись с необходимостью накинуть админку например на сервелате или требование реализовать мобайл клиент на этом сервелате, окажется что нет никаких проблем с этим — у микрософта все продумано.

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

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

I>>>>А реально soap тот же заметить просто нечем...
IT>>>Можно подумать до soap жизни на земле не было.
I>>При чем здесь жизнь до soap ?

IT>При том, что "реально soap тот же заменить просто нечем".

", потому что на нём держится кучка сервисов." Я готов использовать всё что угодно, но эти сервисы работают на soap даже у конкурентов следовательно, soap заменить нечем.

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

IT>>При том, что "реально soap тот же заменить просто нечем".

I>", потому что на нём держится кучка сервисов." Я готов использовать всё что угодно, но эти сервисы работают на soap даже у конкурентов следовательно, soap заменить нечем.

Т.е. ты всего лишь навсего зыбыл добавить "в моём конкретном случае".

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

AVK>Затем, что иногда этих урлов много и на вход тоже довольно сложная по структуре информация приходит.

Для этого, согласись, можно написать куда более легкую и не замороченную реализацию.

AVK>А вокруг еще какая нибудь аутентификация похитрее.

Разве что. Вот только скорее всего придется использовать аутентификацию что использовалась до этого на сайте (например, нашу или какой-нить ОпенАйДи). RESTful это поддерживает?

AVK>Можно, конечно, все это руками реализовать, но с использованием WCF будет существенно проще.

Честно признаюсь, что на WCF я очень давно не глядел. Я как его увидел, сразу понял, что это полнейший овердизайн. Потому и не следил за его развитием. Если они сделали качественную поддержку REST-а, то возможно многие мои слова я взял бы обратно.

Я тогда, пользуясь случаем, задам несколько вопросов.
Они сделали там сериализацию в JSON?
А возможность поднять сервис без конфигов и сложной инициализации?
Как реализован роутинг?
Если атрибутами, то какими средствами он сопоставляется с методами? Во время компиляции или опять рефлексия?

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

I>>", потому что на нём держится кучка сервисов." Я готов использовать всё что угодно, но эти сервисы работают на soap даже у конкурентов следовательно, soap заменить нечем.

IT>Т.е. ты всего лишь навсего зыбыл добавить "в моём конкретном случае".

Я не понял что ты хотел сказать. М.б. ты считаешь что можно взять да за два денька переписать всю инфраструктуру сервисов для конторы-гиганта которая в топе находится ? Если сможешь, то да, я согласен, что это мой конкретный случай
Куда WS-ReliableMessaging ? Или REST этому уже научился ?

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

I>Я не понял что ты хотел сказать.

Я не понял чего ты не понял

I>М.б. ты считаешь что можно взять да за два денька переписать всю инфраструктуру сервисов для конторы-гиганта которая в топе находится ?

Да будет тебе известно, что отличие конторы-гиганта от конторы не гиганта лишь в том, что в конторе-гиганте легче делаются гигантские ошибки.

I>Если сможешь, то да, я согласен, что это мой конкретный случай

Ну не за два денька, но иногда и таким приходися заниматься — методично устранять чужие гигантские и не очень глупости.

I>Куда WS-ReliableMessaging ? Или REST этому уже научился ?

Без понятия что это за хрень. Она может мне помочь засериализовать граф объектов?

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

AVK>>Затем, что иногда этих урлов много и на вход тоже довольно сложная по структуре информация приходит.
VD>Для этого, согласись, можно написать куда более легкую и не замороченную реализацию.

Не соглашусь. Да, для простейших в плане API сервисов типа гуглевых WCF конечно же оверкилл. В ситуациях же, когда в API фигурируют сотни сущностей и зоопарк разных протоколов WCF очень неплохое решение.

VD>Разве что.

Это лишь один из моментов. А что ты скажешь насчет потоковой передачи? P2P? Дуплекса? Нотификаций? Сохранения стейта между вызовами? Реализовывать все это с нуля поверх голого HTTP стека — полный затрахен.

VD> Вот только скорее всего придется использовать аутентификацию что использовалась до этого на сайте (например, нашу или какой-нить ОпенАйДи).

Это если ты публичный сервис делаешь? А корпоративщики, они много интересной муйни понапридумали на тему.

VD> RESTful это поддерживает?

REST это не специфицирует. Собственно, REST почти ничего не специфицирует, кроме протокола HTTP. Так, набор общих идей.

VD>Если они сделали качественную поддержку REST-а, то возможно многие мои слова я взял бы обратно.

Поддержка там вполне нормальная и без уродливых хвостов типа как WS в сиквел вкрячивали или СО+ в IIS. Благодаря как раз тому якобы овердизайну, который позволил это сделать в рамках штатной архитектуры.

VD>Они сделали там сериализацию в JSON?

Сериализация в JSON не есть обязательное требование для REST. XML там используется не реже. Впрочем, поддержка JSONP там тоже присутствует — все что нужно это пометить требуемый метод атрибутиком [WebGet(ResponseFormat = WebMessageFormat.Json)]

VD>А возможность поднять сервис без конфигов и сложной инициализации?

Без конфигов можно, но не в IIS, только как standalone. Что ты понимаешь под сложной инициализацией я ХЗ — в простейшем случае достаточно просто подсунуть стандартный уже сконфигурированный биндинг. Это 1-2 строки кода.

VD>Как реализован роутинг?

Есть готовый модуль роутинга. Дальше — тем же атрибутом [WebGet(UriTemplate = "...")]. Формат шаблона такой же как для MVC.

VD>Если атрибутами, то какими средствами он сопоставляется с методами? Во время компиляции или опять рефлексия?

Рефлексия. Но один раз сделать это при старте сервиса совершенно не проблема. MVC вон куда больше через рефлексию дергает, и никого вроде это не напрягает.
Впрочем, при желании ты и свой роутер можешь написать, WCF это позволяет.

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

VD>Раньше это был только SOAP.

Блин, как с глухим. WCF с самого начала поддерживал несколько протоколов, не только SOAP.

VD> Теперь вот, оказывается, появился еще REST. Но оба протокола стандартизированы

Нет, REST не стандартизован.

VD>Скажу больше. Если RESTful, который (как оказалось) теперь входит в состав WCF

Точно не читаешь вообще, что тебе пишут. RESTful это не WCF, это так называется любой сервис, соответствующий идеологии REST.

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

I>>Куда WS-ReliableMessaging ? Или REST этому уже научился ?

IT>Без понятия что это за хрень.

Протокол доставки сообщений с гарантией.

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

I>>>Куда WS-ReliableMessaging ? Или REST этому уже научился ?
IT>>Без понятия что это за хрень.
AVK>Протокол доставки сообщений с гарантией.

Это вообще какая-то комбинация слов, не имеющая смысла. А если я компьютер из розетки выдерну, как ты доставку сообщения гарантируешь?

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

VD>Честно признаюсь, что на WCF я очень давно не глядел. Я как его увидел, сразу понял, что это полнейший овердизайн. Потому и не следил за его развитием. Если они сделали качественную поддержку REST-а, то возможно многие мои слова я взял бы обратно.

VD>Я тогда, пользуясь случаем, задам несколько вопросов.
VD>Они сделали там сериализацию в JSON?
Да, еще в .NET 3.5 SP1

VD>А возможность поднять сервис без конфигов и сложной инициализации?
Это как? Две строки задать binding — сложная инициализация? Конфиг чаще всего не нужен, но с ним проще работать, так как можно поменять вообще все (протокол, формат, шифрование) не меняя кода.

VD>Как реализован роутинг?
Атрибутами

VD>Если атрибутами, то какими средствами он сопоставляется с методами? Во время компиляции или опять рефлексия?
Рефлексия, а смысл что-то другое делать? Тупо на десериализацию больше уйдет времени.

А еще есть wcf data services — самое то для JS на клиенте.

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

IT>Это вообще какая-то комбинация слов, не имеющая смысла. А если я компьютер из розетки выдерну, как ты доставку сообщения гарантируешь?

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

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

I>>Куда WS-ReliableMessaging ? Или REST этому уже научился ?

IT>Без понятия что это за хрень. Она может мне помочь засериализовать граф объектов?

Это протокол гарантированой доставки сообщений.