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