Как стать автором
Обновить

От простых скриптов к клиент-серверному приложению на WCF своими руками: почему мне нравится работа в CM

Время на прочтение27 мин
Количество просмотров3.6K
Всего голосов 14: ↑13 и ↓1+12
Комментарии14

Комментарии 14

Спасибо за статью! А можете чуть подробней рассказать про CM-команду?
У нас пока очень небольшая и компактная команда СМ – всего два человека.
Роли у нас разделены следующим образом: я тимлид и непосредственно занимаюсь организацией работы, развитием новых направлений и билд процессов. Вот как та же самая система сборки приватных фиксов, т.к. у меня есть определенная экспертиза в данном вопросе. Мой сотрудник занимается поддержкой консервативных билд процессов основных продуктов, поддержкой билд систем на windows/linux окружениях. Плюс на моей совести поддержка документации по процессам в нашей команде, которая также используется и разработчиками. Будет проект расти и усложняться – мы тоже будем расширяться.

WCF, правда? Вроде посмотрел на календарь, июль 2018...

а чем плох WCF в таких задачах?

А чем плох Mainframe? Работает же вроде.

Честно говоря мне тоже непонятен чем плох WCF. А на вопрос вы так и не ответили.

Честно говоря мне странно говорить с людьми которые не понимают чем плох WCF.

Какое то у вас слишком категоричное мышление. А вы не думали, что у каждой технологии есть как преимущества, так и недостатки. Я так понимаю, что в SOAP вы видите одни недостатки. Но их и в REST порядком. Это если не привязываться к .Net в принципе. Да, для многих вещей, особенно публичных REST и .NET Standard отлично подходят, но есть и много других — для которых SOAP и WCF вполне себе хорошее решение.

PS Я вполне себе представляю как недостатки WCF так и преимущества (по крайней мере для меня), то же самое относится и к REST. Но ваш ответ выглядит весьма хамским.

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


Например в .netcore максимум что вы можете сделать, так это сгенерировать WCF клиент. Если вы посещали последние пару лет конференции MS то могли бы заметить как "гигант" открещивается от своего "детища", оправдываясь мол ну кто не совершал ошибок.


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

Речь не шла о том плох или хорош WCF а о целесообразности его использования в наше время.

Внутри корпоративного сектора есть задачи где использовать его вполне себе рационально. Просто потому что у него есть свои плюшки в виде поддержки кучи транспортов, типов сериализации, авторизации и прочее.

Например в .netcore максимум что вы можете сделать, так это сгенерировать WCF клиент.

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

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

Да, он громоздкий, но вот по поводу потребности — не согласен. Тут надо понимать что WCF — это SOAP, который описывается через wsdl. И в net core вы можете сгенерировать клиента к любому SOAP сервису не только WCF. Не обижайте клуб любителей java с их спрингом и прочими плюшками. Нельзя просто так взять и похоронить хороший протокол (по крайней мере для корпоративного сектора).
Внутри корпоративного сектора есть задачи где использовать его вполне себе рационально. Просто потому что у него есть свои плюшки в виде поддержки кучи транспортов, типов сериализации, авторизации и прочее.

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


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

Кстати это вы не обижайте клуб java и spring. По умолчанию в spring нет никакой поддержки SOAP. В spring ядре у вас только IoC с плюшками, в вебе у вас REST + MVC framework, а вот если вам поизвращаться с SOAP то тогда вам нужно прицепом spring-ws-core(который тягает aop, dom4j и кучу всякой прочей гадости) и jaxb который настраивается под генерацию когда из WSDL, что крайне неудобно. Так что в java люди как то тяготеют к REST ибо даже в spring это на порядок проще и более востребовано.


В корпоративном секторе чего только не найти, там и COBRA и всякие банковские протоколы годов таки 70ых. SOAP и WSDL это прошлое, смиритесь с этим.

Не хватает главы «Почему я выбрал WCF» :) Ответ: «Потому что на тот момент я не знал ничего другого.» Как я упоминал в статье, мне передали в зону ответственности систему сборки приватных фиксов. Там уже имелся написанный WCF сервис, простенькое веб-приложение.
Я выбрал самый оптимальный вариант — доработать то, что уже есть, а не потратить кучу времени и попытаться сделать что-то с нуля на новых технологиях. В итоге я изучил, что у меня было, почитал статьи в интернете и сделал полезное и рабочее приложение, которое заметно упростило работу не только команде СМ, но и разработчикам. Была даже идея сделать андроид-приложение, чтобы можно было запускать приватные фиксы с телефона и там же проверять их статус. Может и сделаю, если будет свободное время.
доработать то, что уже есть, а не потратить кучу времени и попытаться сделать что-то с нуля на новых технологиях

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


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

Могу согласиться, но надо сделать одно важное допущение — я не разработчик, а конфиг менеджер и программирование — не моя сфера ответственности и интересов. Основная цель статьи показать, что даже минимальные знания в области программирования могут значительно помочь и упростить работу в других областях.
Ведь кто сделает подобное веб-приложение, кроме меня? У разработчиков другие задачи и цели. Для таких задач выделять отдельного разработчика часто бывает слишком жирно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий