Перед изучением WCF по нём есть вопросы (может он мне и не подойдёт).
Годится ли WCF для клиент-серверных приложений когда один сервер и много клиентов?
Если годится, то для локальной конфигурации (когда всё на одной машине) или для удалённой?
Re: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, TrimS, Вы писали:
TS>Перед изучением WCF по нём есть вопросы (может он мне и не подойдёт). TS>Годится ли WCF для клиент-серверных приложений когда один сервер и много клиентов?
Годится, если вы контролируете код и "клиента" и "сервера". Точнее в таком случае это лучший выбор — и просто и быстро.
TS>Если годится, то для локальной конфигурации (когда всё на одной машине) или для удалённой?
Здравствуйте, TK, Вы писали:
TK>Начните с .net core. для клиент-серверных приложений там есть webapi
Не надо начинать. Сыроват ещё, вплоть до того, что сроки релиза снова вправо поехали.
По сабжу — да, годится, да, работает, да, практически всё, что работает с BasicHttpBinding можно подружить c другими ЯП. С явой/js работало.
Ну и сам вопрос немного странный. Как будто есть выбор
Re[2]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, VladCore, Вы писали:
TS>>Годится ли WCF для клиент-серверных приложений когда один сервер и много клиентов? VC>Годится, если вы контролируете код и "клиента" и "сервера". Точнее в таком случае это лучший выбор — и просто и быстро.
Ну а если не контролируете, вариант-то какой?
Re[3]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, Sinix, Вы писали:
TK>>Начните с .net core. для клиент-серверных приложений там есть webapi S>Не надо начинать. Сыроват ещё, вплоть до того, что сроки релиза снова вправо поехали.
Ключевое слово тут "поехали". Серверный кусок WCF куда сейчас едет?
S>По сабжу — да, годится, да, работает, да, практически всё, что работает с BasicHttpBinding можно подружить c другими ЯП. С явой/js работало.
S>Ну и сам вопрос немного странный. Как будто есть выбор
Есть ещё DCOM, .NET Remoting, WebServices и другие не менее перспективные технологии. Их тоже можно подружить с Явой/js
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[4]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, TK, Вы писали:
TK>Ключевое слово тут "поехали". Серверный кусок WCF куда сейчас едет?
Никуда, не портирован пока. TK>Есть ещё DCOM, .NET Remoting, WebServices и другие не менее перспективные технологии. Их тоже можно подружить с Явой/js
Не надо откапывать стюардессу
Wcf/webapi — наше всё на ближайшие лет 10. Но webapi для приличия ещё надо обзавестись стандартной автодокументацией, хотя бы swagger прикрутили.
И кодогенератором клиентов в пару (где-то в asure sdk есть один, по отзывам — тоже недоделан).
Не, коммунити от безысходности депит костыли типа такого, но это точно не то, с чего стоит начинать знакомиться с сабжем.
Re[4]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, TK, Вы писали:
TK>Есть ещё DCOM, .NET Remoting, WebServices и другие не менее перспективные технологии. Их тоже можно подружить с Явой/js
DCOM — ни в коем разе.
Во-первых, с документацией по конфигурированию всё очень плохо, коды ошибок тоже не очень помогают понять "почему не работает" (а на соседней машине — работает). Во-вторых, за необходимость перезагружать машину после изменений DCOM-конфига (без какого-либо намёка на то через UI) авторов очень хочется расстрелять, затем реанимировать и снова расстрелять, но уже в продакшн-версии. А если какие-то секурити-политики переопределены на уровне доменного контроллера, то застрелиться лучше самому и заранее.
Re[5]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, Mr.Delphist, Вы писали:
MD>DCOM — ни в коем разе. MD>Во-первых, с документацией по конфигурированию всё очень плохо, коды ошибок тоже не очень помогают понять "почему не работает" (а на соседней машине — работает).
Вот про коды ошибок — не надо. В DCOM ошибку можно вернуть любой степени подробности.
В .net класс exception это лишь часть соглашения в с#. никто не запрещает вам кидать/ловить int или тупо bool.
Не надо путать архитектуру и детали реализации с синтаксическим сахаром
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[5]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, Sinix, Вы писали:
TK>>Ключевое слово тут "поехали". Серверный кусок WCF куда сейчас едет? S>Никуда, не портирован пока. TK>>Есть ещё DCOM, .NET Remoting, WebServices и другие не менее перспективные технологии. Их тоже можно подружить с Явой/js S>Не надо откапывать стюардессу S>Wcf/webapi — наше всё на ближайшие лет 10. Но webapi для приличия ещё надо обзавестись стандартной автодокументацией, хотя бы swagger прикрутили.
Это не стюардесса, а рыба. а рыба может быть только первой свежести и компромиссы на 10 лет тут не уместны.
S>И кодогенератором клиентов в пару (где-то в asure sdk есть один, по отзывам — тоже недоделан).
кодогенератор под azure это вендор-лок который еще и поискать надо.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[6]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, TK, Вы писали:
S>>Wcf/webapi — наше всё на ближайшие лет 10. Но webapi для приличия ещё надо обзавестись стандартной автодокументацией, хотя бы swagger прикрутили. TK>Это не стюардесса, а рыба. а рыба может быть только первой свежести и компромиссы на 10 лет тут не уместны.
Чо-то у нас непонимание какое-то.
Про стюардессу — эт про перечисленные тобой варианты (DCOM и ко). У wcf как у полноценного сетевого стека альтернативы на сегодня нет. Место хипстер-апи прочно занято webapi. Какие ещё варианты?
S>>И кодогенератором клиентов в пару (где-то в asure sdk есть один, по отзывам — тоже недоделан). TK>кодогенератор под azure это вендор-лок который еще и поискать надо.
Угу. Я в том смысле, что хоть какой-то смогли же сделать.
Re[6]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Mr.Delphist, Вы писали:
MD>>DCOM — ни в коем разе. MD>>Во-первых, с документацией по конфигурированию всё очень плохо, коды ошибок тоже не очень помогают понять "почему не работает" (а на соседней машине — работает).
TK>Вот про коды ошибок — не надо. В DCOM ошибку можно вернуть любой степени подробности.
Из своего кода — конечно, можно. Но когда этот код ошибки тебе отдаёт сама система, и гуглёж кода ошибки (и столь же "информативного" сообщения в системном логе) сводится к фразе "у системы что-то не получилось", то телепатилка помогает далеко не всегда. Почему не инстанциируется объект? Хз. Почему сфейлился вызов метода (причём до той стороны не дойдя, ибо в логе пусто)? Хз. Почему на соседней тачке всё это работает без проблем? Хз. Вот такой вот hz-oriented DCOM.
Re[7]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, Sinix, Вы писали:
Место хипстер-апи прочно занято webapi. Какие ещё варианты?
Уже года 3 юзаем в ентерпрайзе. проекты до 20 человеколет — ни единого разрыва. Генератор доки там уже тоже давно имеется: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages
генератор клиента не помешал бы, но в 9 случаях из 10 — фиддлера хватает с головой.
WCF — ф топку к предыдущим выкопанным стюардессам. Если канечно кейс не особо экзотичный.
I>Уже года 3 юзаем в ентерпрайзе. проекты до 20 человеколет — ни единого разрыва. Генератор доки там уже тоже давно имеется: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages
Я не про справку, а про стандартный формат метаданных, который всем понимается. Чтоб можно было, скажем, взять swagger и получить готовое API на шарпе/ts/яваандроиде. И обновлять его автоматом, без отслеживания каждой правки вручную.
Без этого писать что-то масштабное, хотя бы с парой сотен эндпойнтов... манал я такое счастье, пардон мой французский.
I>WCF — ф топку к предыдущим выкопанным стюардессам. Если канечно кейс не особо экзотичный.
+100500.
Проблема с энтерпрайзом в том, что там чуть ли не каждый кейс экзотичный. Как только доходит до ситуации "мы не можем вытянуть логику на одной машине", надо прикрутить рич-клиента или хотя бы queuing, как концепция "service statelessness подходит всем" идёт лесом и начинается голимое велосипедостроение.
Прелесть WCF в том, что он содержит основные велосипеды из коробки и более того, они практически работают.
Re[9]: Годится ли WCF для клиент-серверных приложений?
Здравствуйте, Sinix, Вы писали:
S>Я не про справку, а про стандартный формат метаданных, который всем понимается. Чтоб можно было, скажем, взять swagger и получить готовое API на шарпе/ts/яваандроиде. И обновлять его автоматом, без отслеживания каждой правки вручную.
Ну вот нет стандартного формата метаданных в ресте. С учетом того что чуть чаще чем обычно клиент написан на js — это и неудивительно.
S>Без этого писать что-то масштабное, хотя бы с парой сотен эндпойнтов... манал я такое счастье, пардон мой французский.
Практика показывает что не все так печально. Ток тестами надо обложиться со всех сторон.
S>Проблема с энтерпрайзом в том, что там чуть ли не каждый кейс экзотичный. Как только доходит до ситуации "мы не можем вытянуть логику на одной машине", надо прикрутить рич-клиента или хотя бы queuing, как концепция "service statelessness подходит всем" идёт лесом и начинается голимое велосипедостроение.
Обычно удается все свести к типовому солюшну. В данном конкретном случае, например, прикручаешь какой нить редис в виде распределенного кеша и скейлишься стейтфул сколько надо.
S>Прелесть WCF в том, что он содержит основные велосипеды из коробки и более того, они практически работают.
Это да, по сравнению со кастомным велосипедом он выигрывает.
