Ц# + АСП.НЕТ въпрос .........
10 отговора
265 прегледа
Ц# + АСП.НЕТ въпрос .........
Здравейте !!!
Искам да попитам тук за нещо, което ме интересува отдавна /сравнително / ...
И по-точно : каква е вашата практика за случая който ще опиша по-долу ....
А именно :
Имаме Уеб приложение , от тип /както някъде четох наскоро/ "Фронт контролер", тоест има само една Уеб страница и в зависимост от избора на потребителя се генерира нейното съдържание на сървъра , след което изплюва ХТМЛ -а ...Менютата са от тип LinkButton /сървърни контроли/...
За да определя какъв е избора на потребителя , още в началото на Page_Load , записвам стойността на променливата Request.Params["__EVENTTARGET"] в Session променлива, която съдържа ID на контрола ,който е стартирал събитието /в случая ID-to на някой от LinkBotton-ите/ и в зависимост от тази стойност се изгражда и самата страница ....Но честно казано , въпреки че този начин работи безпроблемно, нещо ме човърка от вътре , и все си мисля ,че има и друг начин....
Тъй като тепърва трупам опит в Уеб програмирането , все още някои от нещата ги пробвам по начина "Опит->Грешка"....Поради това , първоначално си мислех че това определяне на избора може да се определи при събитието OnClick на съответния бутон ...Но това не става ,тъй като първо се генерира УебСтраницата и след това се изпълнява кода от събитието/което си е и логичното/ ...А на мен ми трябва да знам неговия избор още в началото на генерирането на страницата....
Та молбата ми е, някой да сподели как се справя той с тази ситуация ....
P.S. -> Става въпрос за C# и ASP.NET ..............
Искам да попитам тук за нещо, което ме интересува отдавна /сравнително / ...
И по-точно : каква е вашата практика за случая който ще опиша по-долу ....
А именно :
Имаме Уеб приложение , от тип /както някъде четох наскоро/ "Фронт контролер", тоест има само една Уеб страница и в зависимост от избора на потребителя се генерира нейното съдържание на сървъра , след което изплюва ХТМЛ -а ...Менютата са от тип LinkButton /сървърни контроли/...
За да определя какъв е избора на потребителя , още в началото на Page_Load , записвам стойността на променливата Request.Params["__EVENTTARGET"] в Session променлива, която съдържа ID на контрола ,който е стартирал събитието /в случая ID-to на някой от LinkBotton-ите/ и в зависимост от тази стойност се изгражда и самата страница ....Но честно казано , въпреки че този начин работи безпроблемно, нещо ме човърка от вътре , и все си мисля ,че има и друг начин....
Тъй като тепърва трупам опит в Уеб програмирането , все още някои от нещата ги пробвам по начина "Опит->Грешка"....Поради това , първоначално си мислех че това определяне на избора може да се определи при събитието OnClick на съответния бутон ...Но това не става ,тъй като първо се генерира УебСтраницата и след това се изпълнява кода от събитието/което си е и логичното/ ...А на мен ми трябва да знам неговия избор още в началото на генерирането на страницата....
Та молбата ми е, някой да сподели как се справя той с тази ситуация ....
P.S. -> Става въпрос за C# и ASP.NET ..............
Re: Ц# + АСП.НЕТ въпрос .........
Определено си прав, че не това трябва да е начина. Това, което си направил е някакъв доста брутален work-around, и ще е добре да го преправиш.
Интересното е че в началото си бил на прав път - начина да се направи това е именно със евент-хандлер на OnClick на съответния бутон. Въпреки, че евента действително се вика след Page_Load (където предполагам имаш някакъв код), не би трябвало да има никакъв проблем кода във евент-ханлдъра да ти промения страницата спрямо това кой бутон е бил натиснат.
Тоест това, което правиш в Page_Load би трябвало лесно да се премести във евент-хандлер на OnClick.
Интересното е че в началото си бил на прав път - начина да се направи това е именно със евент-хандлер на OnClick на съответния бутон. Въпреки, че евента действително се вика след Page_Load (където предполагам имаш някакъв код), не би трябвало да има никакъв проблем кода във евент-ханлдъра да ти промения страницата спрямо това кой бутон е бил натиснат.
Тоест това, което правиш в Page_Load би трябвало лесно да се премести във евент-хандлер на OnClick.
Re: Ц# + АСП.НЕТ въпрос .........
До колкото разбирам, искаш да симулираш директно редиректване от LinkButton. Това е хитро, но така ти се губи до известна степен обработката на събитията от контролите, например ако искаш да запишеш нещо в базата данни преди показването на новата страница какво ще правиш? Ако контролите в ASPX-а са едни и същи всичко ще е ОК, но ако се променят (примерно да се зареди ново меню)?
The road to hell is full of good intentions...
The road to hell is full of good intentions...
Re: Ц# + АСП.НЕТ въпрос .........
А защо се опитваш да си правиш фронт контролер? Има ли реална причина или просто си експериментираш?
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: Ц# + АСП.НЕТ въпрос .........
Какво имаш предвид под това да го преправи и защо не ти харесва неговия подход за изграждане на съответното приложение?
Re: Ц# + АСП.НЕТ въпрос .........
Ами общо взето АСП.НЕТ се опитва максимално да пресъздаде илюзията, че програмираш за Уиндоус. Проблема е, че всичко това става през stateless protocol (HTTP) и всичко работи на магия, която се нарича ViewState. При евент при клиента (браузъра) са симулира сървърен-евент както това става и при нормално Уиндоус програмиране, а целия стейт на приложението се персиства във ViewState-а.
Тоест модела на програмиране е event-based - реагираш на някакъв евент със някакъв код. Това, което БОИЛ се опитва да направи, е да "хакне" този модел и да работи все едно како е било едно време класическото АСП или ПХП. Данните във __EVENTARGUMENTS __EVENTTARGET се пазят във <input type="hidden"> и се използват вътрешно от фреймуърка при симулирането на този евент - никога не би трябвало да се аксесват директно от кода на програмиста.
И въобще - по всичко примери в МСДН-а се прави чрез реагиране на евент - така че има нещо като best practice.
Тоест модела на програмиране е event-based - реагираш на някакъв евент със някакъв код. Това, което БОИЛ се опитва да направи, е да "хакне" този модел и да работи все едно како е било едно време класическото АСП или ПХП. Данните във __EVENTARGUMENTS __EVENTTARGET се пазят във <input type="hidden"> и се използват вътрешно от фреймуърка при симулирането на този евент - никога не би трябвало да се аксесват директно от кода на програмиста.
И въобще - по всичко примери в МСДН-а се прави чрез реагиране на евент - така че има нещо като best practice.
Re: Ц# + АСП.НЕТ въпрос .........
Ок според теб как трябва да се деиства в подобна ситуация:
Имаш много текстови полета които потребител трябва да въведе, както и няколко бутона за различни цели и не искаш при всяко натискане на бутон да правиш заявка до сървъра. Трябва да използваш js и след това да изпратиш данните до сървъра със сървърен контрол. Как може това да стане със събития щото аз много си блъсках главата и не успях да го натъкмя?
Имаш много текстови полета които потребител трябва да въведе, както и няколко бутона за различни цели и не искаш при всяко натискане на бутон да правиш заявка до сървъра. Трябва да използваш js и след това да изпратиш данните до сървъра със сървърен контрол. Как може това да стане със събития щото аз много си блъсках главата и не успях да го натъкмя?
Re: Ц# + АСП.НЕТ въпрос .........
Честно казано, не разбирам добре точно проблема. Бутоните, които не трябва да генерират сървърни евенти, а само клиентски, могат спокойно да се дефинират със <input type=button onclick="someJavaScriptFunction()">
Бутона, който трябва да ти генерира сървърен евент си го генерираш със
<asp:button runat="server" OnClick="SomeSeрverEventHandlerМеthod" />
Ако постнеш малко код и/или детайли, може би ще ми стане по-ясно и евентуално бих могъл да постна повече информация.
Бутона, който трябва да ти генерира сървърен евент си го генерираш със
<asp:button runat="server" OnClick="SomeSeрverEventHandlerМеthod" />
Ако постнеш малко код и/или детайли, може би ще ми стане по-ясно и евентуално бих могъл да постна повече информация.
Re: Ц# + АСП.НЕТ въпрос .........
В момента обмислям варианта , в който използвам онКлик събитията , като в Пейдж_Лоад да си остане само кода ,който не зависи от менутата , а в онКлик на съответния бутон да се обработва останалия код...Въпреки ,че всичко доста ще усложни като логика и последователност, аз също си мисля ,че това е правилния начин /поне за в моя случай /....
Благодаря на всички за отговорите и предложенията !
Всичко най-добро!
Благодаря на всички за отговорите и предложенията !
Всичко най-добро!
Re: Ц# + АСП.НЕТ въпрос .........
Някой сеща ли се как може най-ефективно да се направи пейджинг на страница т.е. ( ако например ползваш Repeater ) и искаш да ти се появяват определен брой резултати на страница. Аз се сещам как да го направя като се презарежда датасета с данните на всяка нова страница.
А дали ще е ефективно ако датасета се запазва в кеш или пък в някаква променлива на сесията или нещо подобно.
А дали ще е ефективно ако датасета се запазва в кеш или пък в някаква променлива на сесията или нещо подобно.
Re: Ц# + АСП.НЕТ въпрос .........
Ами то няма "най-ефективен" начин, просто въпроса е какво искаш да максимизираш. Основните фактори според мен са:
1) леснота за правене
2) мин натоварване на базата данни
3) мин натоварване на апликейшън сървъра
4) мин натоварване на клиента
Ако искаш да оптимизираш 1), тогава правиш пейджинг с DataGrid - има си вграден пейждинг лесен за имплементиране и не се занимаваш много много.
Ако искаш да оптимизираш 2) тогава правиш запитаването само веднъж и кешираш резултата в паметта на апликейшън сървъра. АСП.НЕТ има доста як Cache object, който се ползва толкова лесно колкото и Session. Но това става само за малко юзърс - примерно интранети някви.
Ако искаш да оптимизираш 3) тогава си правиш SQL query всеки път при всяко кликане на нова страница и не кешираш нищо.
4) Тука вече много зависи. Примерно може под оптимизиране за клиента да се разбира по-малки страници, че да не чака много докато се зареждат. Много големите DataGrid (примерно 500 резултата на страница) генерират адски много ViewState и се зареждат много бавно. По-малките гридове (примерно 20 на страница) ще изискват много натискания прев/некст което пак е време и натоварва и сървъра. Много зависи просто. Понякога е добре да изключиш ViewState-а на грид-а (EnableViewState="False") и да rebind-ваш всеки път дори и след постбак - това ще натовари повече сървъра, но ще спести примерно 100Кб ViewState, което може да е важно ако връзката на клиентите не е добра.
В общия случай караш по-точка 1) и само ако наистина почне много да се бави Грид-а почваш да търсиш какво/къде се бави и как да го оптимизираш.
1) леснота за правене
2) мин натоварване на базата данни
3) мин натоварване на апликейшън сървъра
4) мин натоварване на клиента
Ако искаш да оптимизираш 1), тогава правиш пейджинг с DataGrid - има си вграден пейждинг лесен за имплементиране и не се занимаваш много много.
Ако искаш да оптимизираш 2) тогава правиш запитаването само веднъж и кешираш резултата в паметта на апликейшън сървъра. АСП.НЕТ има доста як Cache object, който се ползва толкова лесно колкото и Session. Но това става само за малко юзърс - примерно интранети някви.
Ако искаш да оптимизираш 3) тогава си правиш SQL query всеки път при всяко кликане на нова страница и не кешираш нищо.
4) Тука вече много зависи. Примерно може под оптимизиране за клиента да се разбира по-малки страници, че да не чака много докато се зареждат. Много големите DataGrid (примерно 500 резултата на страница) генерират адски много ViewState и се зареждат много бавно. По-малките гридове (примерно 20 на страница) ще изискват много натискания прев/некст което пак е време и натоварва и сървъра. Много зависи просто. Понякога е добре да изключиш ViewState-а на грид-а (EnableViewState="False") и да rebind-ваш всеки път дори и след постбак - това ще натовари повече сървъра, но ще спести примерно 100Кб ViewState, което може да е важно ако връзката на клиентите не е добра.
В общия случай караш по-точка 1) и само ако наистина почне много да се бави Грид-а почваш да търсиш какво/къде се бави и как да го оптимизираш.