Комментарии 18
2020 год, вы всерьез про WCF???
Через год будет статья про WCF -> gRPC.
Не будет, к сожалению. Не взлетело.
Планируете ли на что-нибудь мигрировать в свете отсутствия wcf в актуальных версиях .net?
Расскажите про опыт grpc, это актуальный вопрос для тех кто думает на что менять wcf.
IMHO, смысла что-то срочно куда-либо мигрировать вообще очень мало. Мой опыт показывает, что реальной необходимости миграции в большинстве случаев нет. Есть требования заказчика, сформированные в результате прочтения статей о том, что «все системы такого-то типа должны обладать таким-то набором функций» (список из 10-20 позиций, из которых заказчик будет использовать хорошо если 2-3). Есть стремление всего более нового, вне зависимости от того, сколько будет стоить обновить инфраструктуру до требуемого уровня. Есть надежды на серебрянную пулю (типа «вот переведу свою систему в облака/микросервисы — и сразу заживу!»). А есть, наоборот, дремучее легаси, которое написано ещё до твоего рождения и уже не одно десятилетие портит людям кровь, но никто его не будет менять из риска хоть что-то потерять — а с ним тоже взаимодействовать надо. Повторяю, это только IMHO, но я очень мало видел примеров того, как миграция на новые инструменты или версии приносила реальные преимущества, а не тонну геморроя.
Пример: примерно раз в два года наша компания «перезжает» на новую версию Visual Studio. Разрабатываемое решение большое, проектов в нём много, разных типов, покрытие тестами — моё почтение. Каждый раз при переезде примерно месяц у всей команды (не одна сотня человек) проект будет или не открываться, или не компилироваться, или не работать, или значительная часть тестов упадёт. Я не говорю уже про тормоза и зависания новой версии первые полгода или отваливающиеся расширения и дополнения среды разработки.
grpc — не исключение. WCF нет в актуальных версиях? А что из предоставляемых в актуальных версиях планируется использовать? А почему архитектура организована таким образом, что проект зависит от фреймворков? А если с архитектурой всё хорошо, то откуда проблемы с миграцией?
P.S.: Извините за «простыню». Так получается…
Пример: примерно раз в два года наша компания «перезжает» на новую версию Visual Studio. Разрабатываемое решение большое, проектов в нём много, разных типов, покрытие тестами — моё почтение. Каждый раз при переезде примерно месяц у всей команды (не одна сотня человек) проект будет или не открываться, или не компилироваться, или не работать, или значительная часть тестов упадёт. Я не говорю уже про тормоза и зависания новой версии первые полгода или отваливающиеся расширения и дополнения среды разработки.
grpc — не исключение. WCF нет в актуальных версиях? А что из предоставляемых в актуальных версиях планируется использовать? А почему архитектура организована таким образом, что проект зависит от фреймворков? А если с архитектурой всё хорошо, то откуда проблемы с миграцией?
P.S.: Извините за «простыню». Так получается…
Если вы делаете в одиночку что-то для «заказчика», то, конечно, ему не важно, хоть на Delphi можно делать.
Когда же ищешь людей в команду, то все сложнее и сложнее искать их на устаревшие технологии.
Что такого в новых версиях? Возможности языка, например, новые появляются. Какие-то готовые решения со временем перестают появляться для старого или появляются с задержкой или их выбор не велик и не радует качеством.
А архитектура, уж извините, организована как организована… не бывает архитектур, приспособленных к любым поворотам в которые их может занести. Или бывает, но долго, дорого и никому не нужно.
На самом деле, меня больше интересовал практический вопрос, что не полетело в grpc, т.к. сам на него поглядываю как на потенциальную замену wcf.
В grpc не полетело его несуществование на момент разработки описываемого проекта. Мы релизнулись в октябре 2014, а grpc был представлен в августе 2016.
Если вопрос будет про «что лучше использовать сейчас?», я отвечу «а что лично Вам удобнее?» Я, поизучав grpc, для своих маленьких проектов с клиент-серверным взаимодействием остановился на WCF. Что я буду использовать, когда мне дадут enterprise-проект, связанный с клиент-сервером? Буду посмотреть в конкретной ситуации. Может — grpc, может — wcf, а может и cgi, реализованный на ассемблере. Всё от конкретных требований.
Если вопрос будет про «что лучше использовать сейчас?», я отвечу «а что лично Вам удобнее?» Я, поизучав grpc, для своих маленьких проектов с клиент-серверным взаимодействием остановился на WCF. Что я буду использовать, когда мне дадут enterprise-проект, связанный с клиент-сервером? Буду посмотреть в конкретной ситуации. Может — grpc, может — wcf, а может и cgi, реализованный на ассемблере. Всё от конкретных требований.
НЛО прилетело и опубликовало эту надпись здесь
gRPC — лишь временный хайп для школотронов. Индустрии этот гугловысер не особо нужен.
Изобретать велосипеды – это плохо.
Не всегда. Куда хуже всю жизнь ездить на треугольных колёсах, хотя умом понимаешь, что круглые куда лучше. Важно понимать, что именно ты улучшаешь «велосипедом» (а не просто NIH) и насколько перспективно делать лисапед в сравнении с существующим решением.
Например, тот же убогий микрософт до сих пор не умеет правильный HTTP!
… свою систему мы начали масштабировать во всех направлениях, а собственные обёртки стали самым узким местом проекта. Тогда я почитал про WCF
Вообще не понял связи. WCF — это вообще не про масштабирование, а натягивание совы на глобус. Практически все «сетевые убожества» можно спокойно масштабировать предварительным load balancer'ом, причём код серверов вообще менять не придётся.
Походу, автор из одной крайности свалился в другую. WCF — это зло, просто запомните и никогда не используйте.
Например, тот же убогий микрософт до сих пор не умеет правильный HTTP!
Там какой-то программист-истеричка писал :)
Высокоуровневые абстракции ему не нравятся т.к. «не круто», низкоуровневыми он пользоваться не умеет.
О! Подтянулись диванные иксперды, «мнение имеющие». А ничего, что своим тупым комментом ты позоришь себя, при этом даже не поняв сути поста? Остынь, отрок! Твоё бесценное мнение без единого аргумента ты ещё успеешь озвучить в школе.
Действительно какая-то бредятина. Во-первых, есть возможность натравить по очереди несколько Reader'ов на один поток, не закрывая его, и это решит проблему; во-вторых можно вычитать все данные и руками отсечь нужное начало — решается кучей способов, на ум сразу приходит пример с файлами сертификатов. имеющих заранее известные начало и конец. Язык программирования не обязан решать любую проблему, но вполне достаточно, когда он предоставляет удобные инструменты для её решения, и здесь их вполне достаточно.
WCF в своё время был вполне эффективным средством внутрисетевого взаимодействия. Ныне неактуально.
WCF в своё время был вполне эффективным средством внутрисетевого взаимодействия. Ныне неактуально.
Во-первых: вы кормите тролля.
Во-вторых:
К сожалению, это не пройдет с большинством XXXReader из .NET т.к. они любят заполнять внутренний буфер и уже из него читать. Т.е. выбросив первый Reader вы выбросите N байт буфера который он прочитал «прозапас».
Единственный рабочий вариант это ваш второй — вычитать байты в буфер/массив буферов, найти там какую-то известную последовательность, в HTTP это конец заголовков "\r\n\r\n" и уже парсить содержимое.
Тут .NET предоставляет просто вереницу инструментов, стримы, байтовые массивы, пулы массивов, и супер удобный PipeReader.
Во-вторых:
Во-первых, есть возможность натравить по очереди несколько Reader'ов на один поток, не закрывая его, и это решит проблему;
К сожалению, это не пройдет с большинством XXXReader из .NET т.к. они любят заполнять внутренний буфер и уже из него читать. Т.е. выбросив первый Reader вы выбросите N байт буфера который он прочитал «прозапас».
Единственный рабочий вариант это ваш второй — вычитать байты в буфер/массив буферов, найти там какую-то известную последовательность, в HTTP это конец заголовков "\r\n\r\n" и уже парсить содержимое.
Тут .NET предоставляет просто вереницу инструментов, стримы, байтовые массивы, пулы массивов, и супер удобный PipeReader.
Господа, не стоит холиварить за инструменты. Их было много, и их ещё больше будет. За свои 20 лет активного программирования я насмотрелся всякого: и забивания гвоздей микроскопами (с неизменным выводом «эти ваши микроскопы все гамно»), и выдающегося применения совершенно неподходящих для этого вещей («в умелых руках и срамной уд — балалайка»). Весь смысл статьи (помимо очевидной горькой самоиронии) заключён во втором её выводе: последовательное повторное решение задачи с помощью изменяющихся инструментов ведёт к углубленному изучению этих самых инструментов и связанных с ними технологий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного о велосипедах