hVosttя не говорил, что синхронную фигню нельзя превратить в асинк.
А что ты говорил? Внятно сформулируй мысль - для какой задачи и что тебе надо?

hVosttтем более с таскфектори надо связать канселлер, обрабоотку исключений...
Пипец как сложно, просто неподъемная задача





hVosttэто всё должно быть внутрях. чтобы я сделал await, а не ипался с таском.
Не знаю, вот сколько уже работаю с дотнетом и сериализацией/десериализацией, мне такого еще не понадобилось. Ты там терабайты json что-ли пилишь, признавайся? Тогда точно TPL нужен

hVosttперечитай свой код и найди затык на 3-ей строчке кода функции Index()
И в чем там затык?

hVosttМСУВсё-таки на WCF с различными байдингами и протоколами я смотрю более оптимистично.
всё ж простые не перегруженные решения двигаются быстрей. не смотря на мощь и возможности WCF. явно пошла трещина между энтерпрайзом и гибкими технологичными решениями ))
Серьезно, лично я бы не стал нигде применять web api, не вижу в нем смысла. REST? Дык WCF тоже так умеет. Роутинг? Тоже самое и там. Почитай мои рецепты на эту тему, если интересно. WCF мощнее и продвинутее.

handmadeFromRuгоспода мы ушли от темы топика, предлагаю закруглятся с лишним. хотя пятница ж)))
+1, офтоп сплошной

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

hVosttпо сути в родном селизаторе нет ни LINQ, ни асинка, и стандарты не держит, требуется какие-то форматеры подключать, которые ещё написать надо.
Ничего этого не надо. Вообще. Для сериализации и десериализации достаточно одной строчки кода. Всё. Остальное пользуешь дальше, исходя из возможностей .NET. И LINQ, и TPL, и прочего.

hVosttМСУНе знаю зачем он тебе. Пиши любой ISO и юзай на здоровье. Причем тут XML?
ну как при чём. взаимозаменяемость призрачная. попрошу в WCF дату и получу хрен с маслом, пока форматер не подрублю. костыли наше всё? ))
Ты не понял, я говорю о штатном сериалайзере + кастомная десериализация. В случае с WCF там всё само делается, ты вообще ничего не пишешь. Так всё в коробке, в том числе кодогенерация сервиса и прокси классов. Всё типизированно и четко.

hVosttесли следовать за мыслью вендора, то асинхронный код должен юзать асинхронные методы. типо так можно построить эффективный автомат. если он будет вываливаться когда надо что-то серилизовать/десирилизовать, это нехорошо.
Если следовать здравой логике, то асинхронный код нужен только там, где этого требует задача. Писать асинхронный код для асинхронного кода - кретинизм высшего пилотажа. Как часто ты через async парсишь json? Только честно.

hVosttну у тебя на любой затык найдётся рецептик, но не об этом же речь. надо лепить сверху обвязку, в виде форматеров, чтобы получить ISO, или таски, чтобы получить асинк. так-то всё решаемо, да
Рецептики сами по себе не рождаются - для их применения нужна конкретная задача и конкретны случай. Обвязок никаких лепить не нужно, нужно уметь пользоваться функционалом, а не тупо по-кодемански бегать за горящими рекламными лампочками. Я уважаю идею минималиста, то есть используешь только то, что требуется для задачи. Мне не нужен комбайн для того, чтобы вскопать квадратный метр грядки картошки. Понимаешь о чем речь?

hVosttМСУТы там терабайты json что-ли пилишь, признавайся? Тогда точно TPL нужен
да при чём тут я. ты сам можешь назвать хоть одну причину, почему майкрософт заюзала мартышкин json.net вместо тёплого лампового нативного?
Ну как это причем тут ты. Я же не со стенкой дискутирую. А почему майкрософт заюзала мартышкин труд - это вопрос к тем упоротым индусам, которые делают из темплейтов новогодние елки. Такие же люди типа тебя, что в гугле попалось самое простое, то и вкорячили. Почему в надежном мощном WCF нет этих пионерских штучек? Потому что это стабильная устоявшаяся технология. А эти все веб апи появляются как грибы по утру, еще только до конца не сформировавшаяся технология. Я не против неё, я против тех дилентантов, кто её пилит.

hVosttспору нет, мощнее. но веб-апи гибче. проще. хостится без IIS. последнее вообче критично до немогу. прям щас работаю над проектом, где используется WebAPI для реализации АПИ, селфхост. мегаудобно, и кода кот наплакал
Да чем оно гибче, я тебя умоляю. WCF тоже хостится без IIS и в селфхосте :) Уууу, хвост, сколько же ты не знаешь и сколько же тебе еще учить и учить... Это веб-сервисы asmx могли хоститься только в IIS ))

hVosttМСУДа я не против нугет пакетов, я против сторонних колхозных грабель, если есть нативные решения. Пусть даже в нативе я больше строк кода напишу, но это будет родной механизм, о котором мне не нужно думать - он всегда работал и будет работать.
есть и в этом истины зерно :)
Ну дык

hVosttтак и знал, что так скажешь
Видишь как тут всё прозрачно :)

hVosttгибкое апи (под чужую среду) и версионность? селфхост? не?
1. Да, гибкое апи (под чужую среду) было доступно еще со времен царя гороха (веб серфисов asmx). Даже фееричная 1С может кодогенерировать свои прокси по WS-ссылке. Знаешь, что такое WS-ссылка? Ладно... у кого я спрашиваю :)
2. Конечно, версионность есть.
3. Селфхост тоже есть.

thresher8кури, как ты выражаешься, Environment.UserInteractive, Debugger.IsAttached. как вариант можно добавить поддержку ключа "--interactive" и запусткатьбся интерактивно. или взять топшелф и не изобретать велосипед
Рассмешил. Твой высер просто шедеврален, те же яйца, приправленные флюентом. Ты действительно считаешь, что этот код лучше обычного штатного конфигурирования вин сервиса?

thresher8кодер-ковбой? хотя да, ошибочк, в таком детском говнокоде и правда нечего тестировать..
Косолапый кодер-бэтмен, покрывающий своей властью этот мир? Нет, просто упоротая мартышка с гранатой в руке в виде флюента. Точно.

thresher8почему сам workitem рещает, с какой перодичностью ему исполняться? это должно приходить извне
Я понимаю, что ты гавнокодер, но не да такой же степени. Ну ладно, если нет мозгов осилить код из 3 строчек, отвечу на вопрос. А кто запретил этому workitem решать, с какой периодичностью ему работать? Если хочешь брать это значение извне (база, конфиг), напиши в геттере Seconds обращение к конфигу. Вот тебе и ивзне.
Собственно, у меня так и работает. Это код сокращенный до максимума, даже реализации IWorkItem вышиты в код сервиса для простоты. Или ты ожидаешь от рецепта какого-то полного 100% решения под все задачи мира? Там просто идея.

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

thresher8а если ты пукнешь, что в Run должен создаватьс отдельнй поток, в котором вся работа и должна происходить, то опять низачот по архитектурге, ибо работа с потоками не есть задача workitemа, там должна быть только логика работы, а не возня с потоками.
И опять двойка. Ты код каким местом читал? Задницей? Оно и видно. Учи TPL - поток создается в самом сервисе через Task.Factory.StartNew и уже в его Action вызывается ExecuteTask(CancellationToken). IWorkItem ничего не знает о потоках, бестолочь.

thresher8с while(true) ты красава, конечно. кондовый busy wait. почитай про wait handle'ы в перерывах межлду говнокодингом
Не вижу проблем с while(true). Что именно смущает? Или просто мочу не удержать?

thresher8а теперь как надо.

предполодим у нас есть N задач T1...TN. получается, что у нас есть к примеру следующее расписние:

через 5 мин надо выполнать задачу T2
через 12 мин после этого -- T7
через 1 мин после этого - T1
и т.д.

по сути -- бесконечное расписание, очень удобно рализуемое через yield

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

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

thresher8МСУРассмешил. Твой высер просто шедеврален, те же яйца, приправленные флюентом. Ты действительно считаешь, что этот код лучше обычного штатного конфигурирования вин сервиса?да, лучше. потому что в топшелфе ты из коробки получеешь возможность работы из консоли, в качестве винсервиса, функционал по установке и деинсталляции, установки разных инстансов итд. ты такой же функционал говнокодить будешь неделю.
Ты упал, что-ли? В обычном вин сервисе точно так же можно "работать" из консоли, по сути это такая же консоль. Установка и деинсталляция - это ты про "InstallUtil MyService.exe"? Даже не смешно - иди расскажи эти бредни своей бабушке
Что там говнокодить, уже всё есть в коробке. Зачем мне разные инстансы, ты упорот?

thresher8МСУА кто запретил этому workitem решать, с какой периодичностью ему работать? Если хочешь брать это значение извне (база, конфиг), напиши в геттере Seconds обращение к конфигу. Вот тебе и ивзне. потому что single responsibility. и что делать, если тебе один и тот же класс воркитема нужно запланировать на "каждые 13" минут и "каждые 3 часа"?
Причем тут single responsibility? Если мне нужно один воркайтем запланировать на "каждые 13" минут и "каждые 3 часа", я либо заюзаю дубликат с новым временем (быстро) или сделаю новый WorkItemBase со своей логикой (дольше). Пока такого не требовалось. Нужно будет, там делов на 10 минут. В WorkItemBase и нужен для замороченных планирований заданий. А IWorkItem - это уже то, с чем работает сам сервис. Не доперло?

thresher8МСУ1. Учи матчасть TPL и не говори глупостей, код выполняется в отдельных тредах.
ты никак дитер болен или ваще упорот. покажи, где в этом куске отдельные треды:



Ты упорот? Это код самого воркайтема, он ничего не должен знать про отдельные треды. Отдельные треды в методе Execute<T> самого сервиса.

thresher8МСУНе вижу проблем с while(true). Что именно смущает? Или просто мочу не удержать?у тебя потоки (ценный ресурс между прочим) большую часть времени страдают х*итой и ничего не делают. это на деццких нагрузках не понять, тут просто придется поверить на слово
Тут вопрос не про нагрузки, а про количество задач.

thresher8МСУКакой-то околопоносный гавно-алгоритм, лишенный самосознания. Давай готовый проект, а там обсудим твоё высер больного воображения.ты хоть понял, что я говорю-то?
Понял. Ты высрал какой-то кал и пытаешься его втереть мне в мозг. Зачем?

hVosttименно поэтому все новые интерфейсы включая тот же EF обзаводятся дополнительными методами *Async(). или думаешь, просто у кого-то где-то зачесалось и хрен знает почему это стало вдруг важным?
Жжешь :) Ты предлагаешь на каждый парсинг или конвертацию писать свой асинк?




hVostt, что ты там куришь?

hVosttи в тоже время ты предпочитаешь рассекать на комбайнах, потому что это круто :) (пас в сторону WCF)
Да, пока я не вижу реальной альтернативы. Веб апи они до сих пор там пилят, постоянно вбрасывают что-то новое, что-то тестируют и мутят. Зачем мне этот зоопарк? Когда устоится, тогда и будем думать. Да и что думать, тоже непонятно. Взяли и тупо сделали урезанного клона. Накуя?

hVosttтогда я не понимаю какое конкретно различие ты проводишь между WebAPI и WCF. чем тебе не угодил веб апи, но угодил ВЦФ.
Прочитай про байдинги WCF, про кодогенерацию прокси, про гибкие настройки коих тьма тьмущая, про dual режим и много чего.

hVosttведь было крутое WCF и никто не жаловался
Мдя... ))

hVosttты понял о чём я
Нифига я не понял. Ты не можешь до сих пор сформулировать мысль, нафига мне эта байда? :)




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

hVosttдаже рядом не клон. вообще другое. для других задач. просто тебе нужен комбаин, как не крути )) ты комбайнёр!
Надо, для других задач, нужно / не нужно, комбайн... Ты там код конкретный пишешь или коллекционируешь фичи библиотеки?

hVosttда знаю, крутая вещь, крутая... но где-то это всё нужно, а где-то нет.
Ну на WCF не экономят. Поднял его в отдельной песочнице и не хай живёт. WCF сила.

hVosttМСУПросто, чтобы было? В топку. Тем более при надобности это и так можно распараллелить прямыми руками во внешнем вызове. Только кому это нах надо.

вот тут всё што надо по этому поводу сказано http://james.newtonking.com/archive/2012/03/20/json-net-4-5-release-1-iso-dates-async-metro-build

кроме того, если позырить в исходниках, там тупо обёртrи с Task.Factory.StartNew(). но это удобно для написания под полностью асинк платформу, типа WebAPI или WindowsStore.
Я же тебе уже показал, как на 2 щелчка сделать асинк. В чем проблема? Мало того, ты это 100% не используешь (не притворяйся), а просто рогом уперся. Так еще ты мне тут гавнокод навязываешь. Зачем?

hVosttстараюсь выбирать оптимальное решение, а не универсальное =) ну а вообще я люблю читать чужой код, смотреть как и что люди делают и учиться на чужих ошибках, а не на своих.
Ну так читай код и учись. Но зачем тянуть всякое гавно в рабочий проект? :)

hVosttгг по счастью МС живёт за счёт ентерпрайза, так что WCF-у ещё жить и жить. а так бы и пусть развиваются обе технологии. только не думаю, что стоит считать вебапи урезанной версией WCF. разные решения так то.
У веб апи есть одно вкусное расширение - одата. Если бы ты был в теме, ты бы сразу козырнул этой фишкой. Да, WCF не поддерживает одата, к сожалению. Но одата еще сыро и уныло. Будем ждать.

hVosttкто навязывает? я навязываю? брось! просто там 2 щелчка, тут 2 щелчка, так и получается портянка ненужной обвязки, которой при иных обстоятельствах просто бы не потребовалась.
Зачем мне щелчки по поделке от пионера? Я лучше пощелкаю натив :)

hVosttа что делать... истиный программер должен быть достаточно ленив, чтобы не писать код, который уже написан кем-то другим, пусть даже и не вендором
Согласен про ленность. Но всё и так уже написано и левотня мне не нужна.

hVosttсырая и не полная. тем более это не фишка самого вебапи, это его расширение.
Вообщем, пока в топку. Потом будет что-то вменяемое, посмотрим, как это можно будет есть.

хвост, handmadeFromRu
Друзья, вообщем, ваша правда :) Кварц - счастье. Посему был выложен честный рецептик. Долго ипался и изучал мукулатуру, как грамотно обвязать всю конфигурацию в нормальном конфиге (а не в унылом флюенте).

P.S. ТС, сорри за офф ))