Въпрос за RIA web services
15 отговора
0 прегледа
Въпрос за RIA web services
Проект - Silverlight4, WCF RIA services за достъп до БД, C#, VS 2010
Тези асинхронни извиквания на уеб сървисите ме убиват. Едно, че правят спагети код, но и никога не знаеш кога ще бъдат извикани и в каква последователност. В нета има решения за симулиране на синхронни извиквания, но ми се струват прекалено усложнени.
Няма ли някое просто и елегантно решение? Ще се радвам някоя добра душа да сподели.
Благодаря предварително!
... for a brief moment it seemed that rock 'n roll would inherit the earth.
Тези асинхронни извиквания на уеб сървисите ме убиват. Едно, че правят спагети код, но и никога не знаеш кога ще бъдат извикани и в каква последователност. В нета има решения за симулиране на синхронни извиквания, но ми се струват прекалено усложнени.
Няма ли някое просто и елегантно решение? Ще се радвам някоя добра душа да сподели.
Благодаря предварително!
... for a brief moment it seemed that rock 'n roll would inherit the earth.
в отговор на rossen genchev
#3
Re: Въпрос за RIA web services
Благодаря! Ще прочета линка.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
Re: Въпрос за RIA web services
Ако дадеш повече подробности ще ти кажа и нещо по-конкретно, ето ти засега само някои общи положения, извлечени от проби, грешки и скъсани нерви с асинхронности. 
В C# съм обработвал само по 1-2 http заявки едновременно и там е лесно, защото един callback е достатъчен, за да управлява всичко. Писал съм обаче хиляда скрейпъри за GreaseMonkey, които обработват по 40-50 заявки едновеременно, някои локални, други римуут,, като понякога се чака по 30 секунди, за да получиш ... timeout.
Предполагам, че си се оплел в спагетите, защото разчиташ на callback functions да се следят една друга. Предлагам ти следния алгоритъм: направи си микродиаграма на кой етап каква информация трябва да е събрана. После за всеки "етап" създай някакъв обект, който да събере нужното. Пусни колбеците да го пълнят, а задай една рекурсивна функция да се самовика през някакви милисекунди и да проверява дали обекта е напълнен. Ако да -> продължаваш нататък, ако не -> чакаш още. Евентуално след известно време функцията може да вдигне иксепшън, ако много е чакано, а обекта нее пълен.
Няма по-чист и разбираем начин да се управляват асинхронни заявки, без такава контролна, рекурсивна функция и временен обект за събраната информация. Тя може да се настрои и да стартира различни неща, в зависимост какво е пълно в обекта, да го чисти, да спира и пуска сървиси и т.н. Принципът е прост и почти универсален, става и за форкинг. А колбеците - само пишат в обекта и нищо друго.
Това е от моя опит, може би някой друг е решил проблема по друг начин.
В C# съм обработвал само по 1-2 http заявки едновременно и там е лесно, защото един callback е достатъчен, за да управлява всичко. Писал съм обаче хиляда скрейпъри за GreaseMonkey, които обработват по 40-50 заявки едновеременно, някои локални, други римуут,, като понякога се чака по 30 секунди, за да получиш ... timeout.
Предполагам, че си се оплел в спагетите, защото разчиташ на callback functions да се следят една друга. Предлагам ти следния алгоритъм: направи си микродиаграма на кой етап каква информация трябва да е събрана. После за всеки "етап" създай някакъв обект, който да събере нужното. Пусни колбеците да го пълнят, а задай една рекурсивна функция да се самовика през някакви милисекунди и да проверява дали обекта е напълнен. Ако да -> продължаваш нататък, ако не -> чакаш още. Евентуално след известно време функцията може да вдигне иксепшън, ако много е чакано, а обекта нее пълен.
Няма по-чист и разбираем начин да се управляват асинхронни заявки, без такава контролна, рекурсивна функция и временен обект за събраната информация. Тя може да се настрои и да стартира различни неща, в зависимост какво е пълно в обекта, да го чисти, да спира и пуска сървиси и т.н. Принципът е прост и почти универсален, става и за форкинг. А колбеците - само пишат в обекта и нищо друго.
Това е от моя опит, може би някой друг е решил проблема по друг начин.
в отговор на rossen genchev
#6
Re: Въпрос за RIA web services
То има подобни варианти, два линка за пример:
- [линк]
- [линк]
но не искам да усложнявам излишно нещата. Оказа се, че има случаи в които, колкото и да не им харесва на МС трябва да се направи синхронно извикване с риск да блокира UI-то.
Благодаря още веднъж!
... for a brief moment it seemed that rock 'n roll would inherit the earth.
- [линк]
- [линк]
но не искам да усложнявам излишно нещата. Оказа се, че има случаи в които, колкото и да не им харесва на МС трябва да се направи синхронно извикване с риск да блокира UI-то.
Благодаря още веднъж!
... for a brief moment it seemed that rock 'n roll would inherit the earth.
Re: Въпрос за RIA web services
Благодаря за идеята. За момента събирам мнения и мисля кой е най-добрия вариант. Общо взето проблемът с асинхронните извиквания се решава с малко спагети код при стартиране на форма/chld window за Силвърлайт/ и затварянето и съответно, но се оказа, че ако пусна последователно няколко извиквания на един и същ сървис в определен ред (което е важно), то те не се изпълняват в "зададения" такъв. Мислех по въпроса да пускам отделна нишка която да следи за върнатия резултат от сървиза, но първо ще пробвам решението на МС - Visual Studio Async CTP.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
в отговор на rossen genchev
#8
Re: Въпрос за RIA web services
async / await е фийчър на c# 5.0 и е "пудра" на callback-а.
Нищо синхронно няма в това.
Нищо синхронно няма в това.
Re: Въпрос за RIA web services
Това е много добра тема...
Да "подчиниш" Силвърлайта на sync requests е наивно.
Ако всяка следваща заявка е зависима от резултата от предната - callback function-те са решението.
Ако зависимостта е от sequential-а - по-добре да се помисли как заявките да се изпълнят последователно на сървърва(след като са "пристигнали" там), отколкото да ги синхронизираш на ниво клиент.
Да, понякога се налага да правиш synchronous requests...Но все пак съм сигурен в едно (може и да не съм прав де), а именно: Да се помисли за ре-дизайн на клиентската част, така, че да не е зависима от синхронизация на заявките.
Да "подчиниш" Силвърлайта на sync requests е наивно.
Ако всяка следваща заявка е зависима от резултата от предната - callback function-те са решението.
Ако зависимостта е от sequential-а - по-добре да се помисли как заявките да се изпълнят последователно на сървърва(след като са "пристигнали" там), отколкото да ги синхронизираш на ниво клиент.
Да, понякога се налага да правиш synchronous requests...Но все пак съм сигурен в едно (може и да не съм прав де), а именно: Да се помисли за ре-дизайн на клиентската част, така, че да не е зависима от синхронизация на заявките.
Re: Въпрос за RIA web services
Ей тук пише, че се компилира с и .НЕТ 4 - [линк]
След инсталацията копира 2 ДЛЛ-а за добавяне на реферънс - 1 за Силвърлайт 4 и 1 за 5-цата. За жалост все още не мога да компилирам и стартирам дори и примерите. които идват след инсталацията на Async CTP.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
След инсталацията копира 2 ДЛЛ-а за добавяне на реферънс - 1 за Силвърлайт 4 и 1 за 5-цата. За жалост все още не мога да компилирам и стартирам дори и примерите. които идват след инсталацията на Async CTP.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
Re: Въпрос за RIA web services
Ами в примерите с Async CTP виждам, че и това правят и което е най-странно няма колбек ф-ии и спагети код. Дажетвърдят, че УИ-то не замръзвало, както при използването на асинхронните извиквания?!? Не знам кво да мисля.
И едно лирично отклонение - идвам от "света" на С++ Буилдера и Indy библиотеката за комуникация. Всички компоненти бяха синхронни, но за да не се блокира интерфацето имаше специален компонент за тази цел. Напълно обратен подход на МС, но определено ми харесва повече.
А иначе си реших проблема по малко селски вариант - извиквания сървиз връща освен всичко друго и нещо като пореден номер, който да ме ориентира кое извикване е завършило. Тъпо, едва ли ще остане освен за проба, но все пак ми върши работа.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
И едно лирично отклонение - идвам от "света" на С++ Буилдера и Indy библиотеката за комуникация. Всички компоненти бяха синхронни, но за да не се блокира интерфацето имаше специален компонент за тази цел. Напълно обратен подход на МС, но определено ми харесва повече.
А иначе си реших проблема по малко селски вариант - извиквания сървиз връща освен всичко друго и нещо като пореден номер, който да ме ориентира кое извикване е завършило. Тъпо, едва ли ще остане освен за проба, но все пак ми върши работа.
... for a brief moment it seemed that rock 'n roll would inherit the earth.
Re: Въпрос за RIA web services
А иначе си реших проблема по малко селски вариант - извиквания сървиз връща освен всичко друго и нещо като пореден номер, който да ме ориентира кое извикване е завършило. Тъпо, едва ли ще остане освен за проба, но все пак ми върши работа.
Точно това имах впревид, а именно: Ако зависиш само от "последователността" на заявките, но не и от "връщания резултат", то по-добре да помислиш за нареждане на тези заявки в опашка на сървъра според сикуенс-а им и след final рикуест статуса на последната да инициираш ъпдейт на базата например.
Синхронизация на ниво Силвърлайт не е най-доброто решение според мен.
Точно това имах впревид, а именно: Ако зависиш само от "последователността" на заявките, но не и от "връщания резултат", то по-добре да помислиш за нареждане на тези заявки в опашка на сървъра според сикуенс-а им и след final рикуест статуса на последната да инициираш ъпдейт на базата например.
Синхронизация на ниво Силвърлайт не е най-доброто решение според мен.
Re: Въпрос за RIA web services
Доколкото ми е известно на този етап - async/await keywords са просто пудра за callback. И не е важно дали се компилират, по-скоро е важно как се компилират.
Дали може да те "спаси" от спагети код - е...със сигурност ще ти помогне в някаква степен, но не решава проблема с синхронността...
По-скоро го приеми като "шорткът" за писане на callback functions, защото в крайна сметка в IL-а ще имаш именно callback functions и нищо повече.
Дали може да те "спаси" от спагети код - е...със сигурност ще ти помогне в някаква степен, но не решава проблема с синхронността...
По-скоро го приеми като "шорткът" за писане на callback functions, защото в крайна сметка в IL-а ще имаш именно callback functions и нищо повече.
Редактирано от Aaron на
Re: Въпрос за RIA web services
Според мен да комилираш още dll-и, за подобно нещо си е като забиване на пирони с микроскоп. 
Ако ще викаш един и същ сървис няколко пъти, защо просто не подредиш заявките една след друга, така че колбека на поредното викане, да вика следващото? Има дребно "наказание" за този тип обръщения, но пък са 100% ефективни, за разлика от другия подход - да хвърлиш всичко едновременно към сървъра и да следиш после какво е пристигнало. Замислял ли си се, че при много заявки, това си е де-факто DOS атака? Да не говорим, че сървъра по някое време може да откаже някоя заявка, просто защото му е препълнен стака (за каква натовареност става въпрос и заявките създават ли нови сесии?).
А най-добрее, както вметна Aaron, да видиш дали всичко не може да стане само с една заявка.
Ако ще викаш един и същ сървис няколко пъти, защо просто не подредиш заявките една след друга, така че колбека на поредното викане, да вика следващото? Има дребно "наказание" за този тип обръщения, но пък са 100% ефективни, за разлика от другия подход - да хвърлиш всичко едновременно към сървъра и да следиш после какво е пристигнало. Замислял ли си се, че при много заявки, това си е де-факто DOS атака? Да не говорим, че сървъра по някое време може да откаже някоя заявка, просто защото му е препълнен стака (за каква натовареност става въпрос и заявките създават ли нови сесии?).
А най-добрее, както вметна Aaron, да видиш дали всичко не може да стане само с една заявка.
Re: Въпрос за RIA web services
ако трябва да сме честни, това е там с причина. основно, да се избегне забиване на UI и да не може програмистите да казват - ами тука чекаме сървъра - а да сложат една иконка "чекам сървъва".
ако те дразни и имаш валидна причина да го направиш, според мен най-добрата ти опция е да си напишеш една малка JavaScript библиотека която ти вика сървъра (jQuery ги има тия готови) и да си викаш нея. Invoke си е синхронна и си готов.
другите хакове ги заеби - не си струват и най-много да се оплетеш още повече в нишки и да те псуват тия след тебе.
ако те дразни и имаш валидна причина да го направиш, според мен най-добрата ти опция е да си напишеш една малка JavaScript библиотека която ти вика сървъра (jQuery ги има тия готови) и да си викаш нея. Invoke си е синхронна и си готов.
другите хакове ги заеби - не си струват и най-много да се оплетеш още повече в нишки и да те псуват тия след тебе.