Предговор към втория том

Ако по принцип не четете уводите на книгите, пропуснете и този. В него ще научите най-вече какво ви предстои в следващите глави и как се стигна до написването на настоящата книга.

Това е втори том на първата чисто българска книга за програмиране с .NET Framework и C#, но въпреки, че фокусира върху .NET Framework 1.1, тя е едно от най-полезните четива в тази област. Написана от специалисти с опит както в практическата работа с .NET, така и в обучението по програмиране, книгата ще ви даде не само основите на .NET програмирането, но и ще ви запознае с някои по-сложни концепции и ще ви предаде от опита на авторите.

За кого е предназначена тази книга?

Вторият том на книгата е предназначен за всички, които са прочели първия том и той им допада. Тя е за всички, които искат да продължат обогатяването на знанията и уменията си за разработка на софтуер за .NET платформата.

Вторият том е просто продължение на първия и включва няколко много важни технологии от .NET Framework, а именно Windows Forms, ASP.NET уеб приложения и уеб услуги.

Тази книга ще ви даде много повече от начални знания. Тя ще ви предаде опит, натрупан в продължение години, и ще ви запознае с утвърдените практики при използването на .NET технологиите.

Книгата е полезна не само за .NET програмисти, но и за всички, които имат желание да се занимават сериозно с разработка на софтуер. В нея се обръща внимание не само на специфичните .NET технологии, но и на някои фундаментални концепции, които всеки програмист трябва добре да знае и разбира.

Необходими начални познания

Тази книга не е подходяща за хора, които никога не са програмирали в живота си. Ако сте абсолютно начинаещ, спрете да четете и просто започнете с друга книга!

Том 2 на книгата не е подходящ за хора, които не са чели (или поне прегледали набързо) първия том. Вторият том е естествено продължение на първия том и е силно свързан с материала, изложен в него. И двете части на книгата са свободно достъпни от Интернет (от адрес http://www. devbg.org/dotnetbook/), така че нямате оправдание да започвате направо от втората. Не ви го препоръчваме!

Какво обхваща вторият том на тази книга?

Програмирането за .NET Framework изисква познания на неговите базови концепции (модел на изпълнение на кода, обща система от типове, управление на паметта, масиви, колекции, символни низове и др.), както и познаване на често използваните технологии – ADO.NET (за достъп до бази от данни), Windows Forms (за приложения с графичен потребителски интерфейс), ASP.NET (за уеб приложения и уеб услуги) и др.

Първият том на книгата обхваща основните концепции в .NET програмирането (от езика C# до ADO.NET), а вторият – по-сложните технологии като Windows Forms, ASP.NET, уеб услуги, нишки, мрежово програмиране, сигурност и др.

Във втория том се обръща внимание на създаването на графичен потребителски интерфейс с Windows Forms и уеб-базирани приложения с ASP.NET. Ще бъдат разгледани и някои по-сложни концепции като отражение на типовете, сериализация, многонишково програмиране, уеб услуги, отдалечено извикване на методи (remoting), взаимодействие с неуправляван код, асемблита, управление на сигурността, по-важни инструменти за разработка и др. Ще бъде разгледана и свободната имплементация на .NET Framework за Linux и други операционни системи Mono. Накрая ще бъде описана разработката на един цялостен практически проект, който обхваща всички по-важни технологии и демонстрира добрите практики при изграждането на .NET приложения.

Фокусът е върху .NET Framework 1.1

Всички теми са базирани на .NET Framework 1.1, Visual Studio .NET 2003 и MS SQL Server 2000. За съжаление по време на изготвянето на текста на книгата (през 2004-2005 г.) версия 2.0 на .NET платформата едва прохождаше и това наложи да не бъдат включени новостите от него.

Надяваме се в следващото издание на книгата авторският колектив да намери време и сили да обнови съдържанието с новостите от .NET 2.0 и да отправи поглед към .NET 3.0.

Как е представена информацията?

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

Настоящата книга е написана от програмисти за програмисти. Авторите са действащи софтуерни разработчици, хора с реален опит както в разработването на софтуер, така и в обучението по програмиране. Благодарение на това качеството на изложението е на много високо ниво.

Всички автори ясно съзнават, че примерният сорс код е едно от най-важните неща в една книга за програмиране. Именно поради тази причина текстът е съпроводен с много, много примери, илюстрации и картинки.

Въобще някой чете ли текста, когато има добър и ясен пример? Повечето програмисти първо гледат дали примерът ще им свърши работа, и само ако нещо не е ясно, се зачитат в текста (това всъщност не е никак добра практика, но такава е реалността). Ето защо многото и добре подбрани примери са един от най-важните принципи, залегнали в тази книга.

Поглед към съдържанието на втория том

Книгата се състои от 29 глави, които поради големия обем са разделени в два тома. Том 1 съдържа първите 14 глави, а том 2 – останалите 15. Това важи само за хартиеното издание на книгата. В електронния вариант тя се разпространява като едно цяло.

Нека направим кратък преглед на всяка една от главите и да се запознаем с нейното съдържание, за да разберем какво ни очаква по-нататък. Главите от втория том можете да намерите в настоящото издание, а останалите – в първи том.

Глава 15. Графичен потребителски интерфейс с Windows Forms

В глава 15 се разглеждат средствата на Windows Forms за създаване на прозоречно-базиран графичен потребителски интерфейс (GUI) за .NET приложенията. Представят се програмният модел на Windows Forms, неговите базови контроли, средствата за създаване на прозорци, диалози, менюта, ленти с инструменти и статус ленти, както и някои по-сложни концепции като: MDI приложения, data-binding, наследяване на форми, хостинг на контроли в Internet Explorer, работа с нишки във Windows Forms и др.

Автори на главата са Радослав Иванов (по-голямата част) и Светлин Наков. Текстът е базиран на лекцията на Светлин Наков по същата тема. Редактори са Светлин Наков и Пламен Табаков.

Глава 16. Изграждане на уеб приложения с ASP.NET

В глава 16 се разглежда разработката на уеб приложения с ASP.NET. Представят се програмният модел на ASP.NET, уеб формите, кодът зад тях, жизненият цикъл на уеб приложенията, различните типове контроли и техните събития. Показва се как се дебъгват и проследяват уеб приложения. Отделя се внимание на валидацията на данни, въведени от потребителя. Разглежда се концепцията за управление на състоянието на обектите – View State и Session State. Демонстрира се как могат да се визуализират и редактират данни, съхранявани в база от данни. Дискутират се разгръщането и конфигурирането на ASP.NET уеб приложенията в Internet Information Server (IIS) и сигурността при уеб приложенията.

Автори на главата са Михаил Стойнов, Рослан Борисов, Стефан Добрев, Деян Варчев, Иван Митев и Христо Дешев. Текстът е базиран на лекцията на Михаил Стойнов по същата тема. Редактори са Иван Митев и Пламен Табаков.

Тази глава беше най-обемната, най-трудната и най-бавно написаната. Поради някои проблемни ситуации в авторския колектив се наложи на няколко пъти да се сменят авторите и това реално забави целия втори том. За радост всичко приключи успешно.

Глава 17. Многонишково програмиране и синхронизация

В глава 17 се разглежда многозадачността в съвременните операционни системи и средствата за паралелно изпълнение на програмен код, които .NET Framework предоставя. Обръща се внимание на нишките (threads), техните състояния и управлението на техния жизнен цикъл – стартиране, приспиване, събуждане, прекратяване и др.

Разглеждат средствата за синхронизация на нишки при достъп до общи данни, както и начините за изчакване на зает ресурс и нотификация при освобождаване на ресурс. Обръща се внимание както на синхронизационните обекти в .NET Framework, така и на неуправляваните синхронизационни обекти от операционната система.

Изяснява се концепцията за работа с вградения в .NET Framework пул от нишки (thread pool), начините за асинхронно изпълнение на задачи, средствата за контрол над тяхното поведение и препоръчваните практики за работа с тях.

Автор на главата е Александър Русев. Текстът е базиран в голямата си част на лекцията на Михаил Стойнов и авторските бележки в нея. редактори са Иван Митев, Георги Митев, Георги Митев, Яни Георгиев и Минчо Колев.

Глава 18. Мрежово и Интернет програмиране

В глава 18 се разглеждат някои основни средства, предлагани от .NET Framework за мрежово програмиране. Главата започва със съвсем кратко въведение в принципите на работа на съвременните компютърни мрежи и на Интернет и продължава с протоколите, чрез които се осъществява мрежовата комуникация. Обект на дискусия са както класовете за работа с TCP и UDP сокети, така и някои класове, предлагащи по-специфични възможности, като представяне на IP адреси, изпълняване на DNS заявки и др. В края на главата ще се представят средствата за извличане на уеб-ресурси от Интернет и на класовете за работа с e-mail в .NET Framework.

Автори на главата са Ивайло Христов и Георги Пенчев. Текстът широко използва лекцията на Ивайло Христов по същата тема. Редактори са Венцислав Попов, Стефан Чанков, Лъчезар Георгиев и Теодор Стоев.

Глава 19. Отражение на типовете (Reflection)

В глава 19 се представя понятието Global Assembly Cache (GAC) и отражение на типовете (reflection). Разглеждат се начините за зареждане на асембли. Демонстрира се как може да се извлече информация за типовете в дадено асембли и за членовете на даден тип. Разглеждат се начини за динамично извикване на членове от даден тип. Обяснява се как може да се създаде едно асембли, да се дефинират типове в него и асемблито да се запише във файл по време на изпълнение на програмата.

Автор на главата е Димитър Канев. Текстът е базиран на лекцията на Ивайло Христов по същата тема. Редактор е Светлин Наков.

Глава 20. Сериализация на данни

В глава 20 се разглежда сериализацията на данни в .NET Framework. Обяснява се какво е сериализация, за какво се използва и как се контролира процесът на сериализация. Разглеждат се видовете форматери (formatters). Обяснява се какво е XML сериализация, как работи тя и как може да се контролира изходният XML при нейното използване.

Автор на главата е Радослав Иванов. Текстът е базиран на лекцията на Михаил Стойнов по същата тема. Редактор е Светлин Наков.

Глава 21. Уеб услуги с ASP.NET

В глава 21 се разглеждат уеб услугите, тяхното изграждане и консумация чрез ASP.NET и .NET Framework. Обект на дискусия са основните технологии, свързани с уеб услугите, и причината те да се превърнат в стандарт за интеграция и междуплатформена комуникация. Представят се различни сценарии за използването им. Разглежда се програмният модел за уеб услуги в ASP.NET и средствата за тяхното изграждане, изпълнение и разгръщане (deployment). Накрая се дискутират някои често срещани проблеми и утвърдени практики при разработката на уеб услуги чрез .NET Framework.

Автори на главата са Стефан Добрев и Деян Варчев. В текста са използвани материали от лекцията на Светлин Наков по същата тема. Технически редактор е Мартин Кулов.

Глава 22. Отдалечено извикване на методи (Remoting)

В глава 22 се разглежда инфраструктурата за отдалечени извиквания, която .NET Framework предоставя на разработчиците. Обясняват се основите на Remoting технологията и всеки един от нейните компоненти: канали, форматери, отдалечени обекти и активация. Дискутират се разликите между различните типове отдалечени обекти. Обясняват се техният жизнен цикъл и видовете маршализация. Стъпка по стъпка се достига до създаването на примерен Remoting сървър и клиент. Накрая се представя един гъвкав и практичен начин за конфигуриране на цялата Remoting инфраструктура чрез конфигурационни файлове.

Автор на главата е Виктор Живков. В текста са използвани материали от лекцията на Светлин Наков. Редактори са Иван Митев и Светлин Наков.

Глава 23. Взаимодействие с неуправляван код

Глава 23 разглежда как можем да разширим възможностите на .NET Framework чрез употреба на предоставените от Windows приложни програмни интерфейси (API). Дискутират се средствата за извикване на функционалност от динамични Win32 библиотеки и на проблемите с преобразуването (маршализацията) между Win32 и .NET типовете.

Обръща се внимание на връзката между .NET Framework и COM (компонентният модел на Windows). Разглеждат се както извикването на COM обекти от .NET код, така и разкриването на .NET компонент като COM обект. Демонстрира се и технологията IJW за използване на неуправляван код от програми, написани на Managed C++.

Автор на главата е Мартин Кулов. Текстът е базиран на неговата лекция по същата тема. Технически редактор е Галин Илиев.

Глава 24. Управление на паметта и ресурсите

В глава 24 се разглежда писането на правилен и ефективен код по отношение използването на паметта и ресурсите в .NET Framework. В началото се прави сравнение на предимствата и недостатъците на ръчното и автоматичното управление на памет и ресурси. След това се разглежда по-обстойно автоматичното им управление с фокус най-вече върху системата за почистване на паметта в .NET (т. нар. garbage collector). Обръща се внимание на взаимодействието с нея и практиките, с които можем да й помогнем да работи възможно най-ефективно.

Автори на главата са Стоян Дамов и Димитър Бонев. Технически редактор е Светлин Наков.

Глава 25. Асемблита и разпространение (deployment)

В глава 25 се разглежда най-малката съставна част на .NET приложенията – асембли, различните техники за разпространение на готовия софтуерен продукт на клиентските работни станции и някои избрани техники за създаване на инсталационни пакети и капаните, за които трябва да се внимава при създаване на инсталационни пакети.

Автор на тази глава е Галин Илиев. В текста е използвана частично лекцията на Михаил Стойнов. Редактор е Явор Янев.

Глава 26. Сигурност в .NET Framework

В глава 26 се разглежда как .NET Framework подпомага сигурността на създаваните приложения. Това включва както безопасност на типовете и защита на паметта, така и средствата за защита от изпълнение на нежелан код, автентикация и оторизация, електронен подпис и криптография. Разглеждат се технологиите на .NET Framework като Code Access Security, Role-Based Security, силно-именувани асемблита, цифрово подписване на XML документи (XMLDSIG) и други.

Автори на главата са Тодор Колев и Васил Бакалов. В текста е широко използвана лекцията на Светлин Наков по същата тема. Технически редактор е Станислав Златинов.

Глава 27. Mono - свободна имплементация на .NET

В глава 27 се разглежда една от алтернативите на Microsoft .NET Framework – проектът с отворен код Mono. Обясняват се накратко начините за инсталиране и работа с Mono, използването на вградените технологии ASP.NET и ADO.NET, както и създаването на графични приложения. Дават се и няколко съвети и препоръки за писането на преносим код.

Автори на главата са Цветелин Андреев и Антон Андреев. Текстът е базиран на лекцията на Антон Андреев по същата тема. Технически редактор е Светлин Наков. Като редактори участват още Соня Бибиликова, Мартин Кирицов, Николай Митев и Александър Николов.

Глава 28. Помощни инструменти за .NET разработчици

В глава 28 се разглеждат редица инструменти, използвани при разработката на .NET приложения. С тяхна помощ може значително да се улесни изпълнението на някои често срещани програмистки задачи. Изброените инструменти помагат за повишаване качеството на кода, за увеличаване продуктивността на разработка и за избягване на някои традиционни трудности при поддръжката. Разглеждат се в детайли инструментите .NET Reflector, FxCop, CodeSmith, NUnit (заедно с допълненията към него NMock, NUnitAsp и NUnitForms), log4net, NHibernate и NAnt.

Автори на главата са Иван Митев и Христо Дешев. Текстът е по техни авторски материали. Редактори са Теодора Пулева и Борислав Нановски.

Глава 29. Практически проект

В глава 29 се дискутира как могат да се приложат на практика технологиите, разгледани в предходните теми. Поставена е задача да се разработи един сериозен практически проект – система за запознанства в Интернет с възможност за уеб и GUI достъп.

При реализацията на системата се преминава през всичките фази от разработката на софтуерни проекти: анализиране и дефиниране на изискванията, изготвяне на системна архитектура, проектиране на база от данни, имплементация, тестване и внедряване на системата.

При изготвяне на архитектурата приложението се разделя на три слоя – база от данни (която се реализира с MS SQL Server 2000), бизнес слой (който се реализира като ASP.NET уеб услуга) и клиентски слой (който се реализира от две приложения – ASP.NET уеб клиент и Windows Forms GUI клиент).

Ръководител на проекта е Ивайло Христов. Автори на проекта са: Ивайло Христов (отговорен за Windows Forms клиента), Тодор Колев и Ивайло Димов (отговорни за уеб услугата и базата данни) и Бранимир Ангелов (отговорен за ASP.NET уеб клиента). Инсталаторът на проекта е създаден от Галин Илиев. Технически редактори на кода са Мартин Кулов, Светлин Наков, Стефан Добрев и Деян Варчев.

Автори на текста са Ивайло Христов, Тодор Колев, Ивайло Димов и Бранимир Ангелов. Технически редактор е Иван Митев. Редактор на текста е Вера Моллова.

Авторският колектив

Авторският колектив се състои от над 30 души – автори, съавтори, редактори и други. Ще представим всеки от тях с по няколко изречения (подредбата е по азбучен ред).

Александър Русев

Александър Русев е програмист във фирма Johnson Controls (www.jci.com), където се занимава с разработка на софтуер за леки автомобили. Завършил е Технически университет – София, специалност компютърни системи и технологии. Александър се е занимавал и с разработка на софтуер за мобилни телефони. Професионалните му интереси включват Java технологиите и .NET платформата. Можете да се свържете с Александър по e-mail: arussev@gmail.com.

Александър Хаджикръстев

Александър Хаджикръстев е софтуерен архитект със сериозен опит в областта на проектирането и разработката на уеб базирани системи и e-commerce приложения. Той е сътрудник и консултант на PC Magazine България (www.sagabg.net/PCMagazine/) и почетен член на Българската асоциация на софтуерните разработчици (www.devbg.org). Александър има дългогодишен опит като ръководител на софтуерни проекти във фирми, базирани в България и САЩ. Професионалните му интереси са свързани с проектирането и изграждането на .NET приложения, разработването на експертни системи и софтуер за управление и автоматизация на бизнес процеси.

Антон Андреев

Антон Андреев работи като ASP.NET уеб разработчик във фирма Elements of Art (www.eoa.bg). Той се интересува се от всичко, свързано с компютрите и най-вече с .NET и Linux. Като ученик се е занимавал с алгоритми и е участвал в олимпиади по информатика. Завършил е математическа гимназия и езикова гимназия с английски език, а в момента е студент в специалност информатика във Факултета по математика и информатика (ФМИ) на Софийски университет "Св. Климент Охридски". Работил е и като системен администратор във ФМИ и сега продължава да подпомага проектите на факултета, разработвайки нови сайтове. Неговият личен сайт е достъпен от адрес: http://debian.fmi.uni-sofia.bg/~toncho/portfolio/. Можете да се свържете с Антон по e-mail: anton.andreev@fmi.uni-sofia.bg.

Бранимир Ангелов

Бранимир Ангелов е софтуерен разработчик във фирма Gugga (www.gugga.net) и студент във Факултета по Математика и информатика на Софийски университет "Св. Климент Охридски", специалност компютърни науки. Неговите професионални интереси са в областта на обектно-ориентирания анализ, моделиране и програмиране, уеб технологиите и в частност изграждането на RIA (Rich Internet Applications) и разработката на софтуер за мобилни устройства. Бранимир е печелил грамоти и отличия от различни състезания, както и първо място на Националната олимпиада по информационни технологии, на която е бил и жури година по-късно.

Васил Бакалов

Васил Бакалов е студент, последен курс, в Американския университет в България, специалност Информатика. Той е председател на студентския клуб по информационни технологии и е студент-консултант на Microsoft България за университета. В рамките на клуба се занимава с управление на проекти и консултации по изпълнението им. Като студент-консултант на Microsoft България Васил подпомага усилията на Microsoft да поддържа тясна връзка със студентите и да ги информира и обучава по най-новите й продукти и технологии. Васил работи и като сътрудник на PC Magazine България от няколко години и има редица статии и коментари в изданието. В университета той предлага и изготвя план за курс по практическо изучаване на роботика, като разширение на обучението по изкуствен интелект, който е одобрен и внедрен. Той работи и с няколко ИТ фирми, където изгражда решения, базирани на .NET платформата. Притежава професионална сертификация от Microsoft. Можете да се свържете с Васил по e-mail: dotnetbook@vassil.info.

Виктор Живков

Виктор Живков е софтуерен инженер в Интерконсулт България (www.icb.bg). В момента е студент в Софийски Университет "Св. Климент Охридски", специалност информатика. Професионалните му интереси са основно в областта на решенията, базирани на софтуер от Microsoft. Виктор има сериозен опит в работата с .NET Framework, Visual Studio .NET и Microsoft SQL Server. Той участва в проекти за различни информационни системи, главно за Норвегия. Членува в БАРС от 2005 година. За връзка с Виктор можете да използвате неговия e-mail: viktor.zhivkov@gmail.com.

Деян Варчев

Деян Варчев е старши уеб разработчик във фирма Vizibility (www.vizibility.net). Неговите отговорности включват проектирането и разработката на уеб базирани приложения, използващи последните технологии на Microsoft, проучване на новопоявяващи се технологии и планиране на тяхното внедряване в производството, както и обучение на нови колеги. Неговите професионални интереси са свързани тясно с технологиите на Microsoft – .NET платформата, SQL Server, IIS, BizTalk и др. Деян е студент по информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски".

Димитър Бонев

Димитър Бонев е софтуерен разработчик във фирма Formula Telecom Solutions (www.fts-soft.com). Той отговаря за разработването на уеб базирани приложения за корпоративни клиенти, както и за някои модули и инструменти, свързани с вътрешния процес на разработка във фирмата. Професионалните му интереси са насочени предимно към .NET платформата, методологията extreme programming и софтуерния дизайн. Димитър е завършил ВВВУ "Г. Бенковски", специалност компютърна техника. Той има богат опит в разработването на софтуерни решения, предимно с технологиите на Microsoft и Borland.

Димитър Канев

Димитър Канев е разработчик на софтуер във фирма Медсофт (www.medsoft.biz). Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Професионалните му интереси са основно в областта на решенията, базирани на софтуер от Microsoft. Димитър има сериозен опит в работата с Visual Studio .NET, Microsoft SQL Server и ГИС системи. Работил е в проекти за изграждане на големи информационни системи, свързани с ГИС решения, и експертни системи за медицински лаборатории.

Галин Илиев

Галин Илиев е ръководител на проекти и софтуерен архитект в българския офис на Technology Services Consulting Group (www.wordassist. com). Галин е участвал в проектирането и разработването на големи информационни системи, Интернет сайтове с управление на съдържанието, допълнения и интеграция на MS Office със системи за управление на документи. Той притежава степен бакалавър по мениджмънт и информационни технологии, а също и сертификация MCSD за Visual Studio 6.0 и Visual Studio .NET. Той има сериозен опит с работата с Visual Studio .NET, MS SQL Server, MS IIS и MS Exchange. Личният му сайт е достъпен от адрес www.galcho.com, а e-mail адресът му е Iliev@galcho.com.

Георги Пенчев

Георги Пенчев е софтуерен разработчик във фирма Symex България (www.symex.bg), където отговаря за разработка на финансово ориентирани графични Java приложения и на Интернет финансови портали с Java и PHP. Участвал е в изграждането на продукти за следене и обработка на борсови индекси и котировки за Българската фондова борса. Георги е студент по информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Професионалните и академичните му интереси са насочени към Java и .NET технологиите, биоинформатикатa, теоретичната информатика, изкуствения интелект и базите от знания. През 2004 и 2005 г. е асистент в курса по "Информационни технологии" за студенти с нарушено зрение и в практическия курс по "Структури от данни и програмиране" в Софийски университет. Можете да се свържете с Георги по e-mail: pench_wot@yahoo.com.

Иван Митев

Иван Митев е софтуерен разработчик във фирма EON Technologies (www.eontechnologies.bg). Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Иван е участвал в проектирането и реализацията на множество информационни системи, основно ГИС решения. Професионалният му опит е в разработки предимно с продукти и технологии на Microsoft. Основните интереси на Иван са в създаването на качествени и ефективни софтуерни решения чрез използването на подходящи практики, технологии и инструменти. Технически уеблог, който той поддържа от началото на 2004 година, е с акцент върху .NET програмирането и е достъпен на адрес http://immitev.blogspot.com. Можете да се свържете с Иван по e-mail: immitev@gmail.com.

Ивайло Димов

Ивайло Димов е софтуерен разработчик във фирма Gugga (www.gugga.com). Неговите интереси са в областта на обектно-ориентираното моделиране, програмиране и анализ, базите от данни, уеб приложенията и приложения, базирани на Microsoft .NET Framework. В момента Ивайло е студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност Компютърни науки. Той е сертифициран от Microsoft разработчик и е печелил редица грамоти и отличия от състезания по програмиране. През 2004 г. е победител в Националната олимпиада по информационни технологии и е участвал в журито на същата олимпиада година по-късно.

Ивайло Христов

Ивайло Христов е преподавател в Софийски университет "Св. Климент Охридски", където води курсове по "Програмиране за .NET Framework", "Качествен програмен код", "Увод в програмирането", "Обектно-ориентирано програмиране" и "Структури от данни в програмирането". Неговите професионални интереси са в областта на .NЕТ технологиите и Интернет технологиите. Като ученик Ивайло е участник в редица национални състезания и конкурси по програмиране и е носител на престижни награди и отличия. Той участва в екип, реализирал образователен проект на Microsoft Research в областта на .NET Framework. Личният сайт на Ивайло е достъпен от адрес: www.ivaylo-hristov.net.

Лазар Кирчев

Лазар Кирчев е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски" и в момента е дипломант в специализация "Информационни системи". Той работи в Института за паралелна обработка на информацията към БАН по съвместен проект между Факултета по математика и информатика и БАН за изграждане на grid система. Неговите интереси включват .NET платформата, grid системите и базите от данни.

Манол Донев

Манол Донев е софтуерен разработчик във фирма telerik (www.telerik. com). Той е част от екипа, който разработва уеб-базираната система за управление на съдържание Sitefinity (www.sitefinity.com). Манол е студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност Информатика. Неговите професионални интереси обхващат най-вече .NET технологиите (в частност ASP.NET уеб приложения, XML и уеб услуги). Можете да се свържете с Манол по e-mail: manol.donev@gmail.com.

Мартин Кулов

Мартин Кулов е сертифициран инструктор и разработчик по програмите Microsoft Certified Trainer (MCT) и MCSD.NET. През 2006 г. е награден от Майкрософт с наградата Most Valuable Professional (MVP). Той е директор направление .NET към Национална академия по разработка на софтуер, където е отговорен за разработка на курсове, обучение и проучване на най-новите технологии на Майкрософт като Visual Studio Team System, Indigo, WSE, ASP.NET, Analysis Services 2005, VSTO, Atlas и др. Мартин е почетен член на Българската асоциация на разработчиците на софтуер (БАРС), член на SofiaDev .NET потребителската група, лектор при международната .NET асоциация - INETA и лектор на редица семинари на Майкрософт. Той е регионален президент на Международната асоциация на софтуерните архитекти (IASA) за България. Неговият личен дневник (блог) може да намерите на адрес http://www.codeattest.com/blogs/martin.

Михаил Стойнов

Михаил Стойнов е софтуерен разработчик във фирма MPS (www.mps.bg), която е подизпълнител на Siemens A.G. Той се занимава професионално с програмиране за платформите Java и .NET Framework от няколко години. Участва като лектор в преподавателския екип на курсовете "Програмиране за .NEТ Framework" и "Качествен програмен код". Той е студент-консултант на Майкрософт България за Софийски университет през последните 2 години и подпомага разпространението на най-новите продукти и технологии на Microsoft в университета. Михаил е бил лектор на международни конференции за ГИС системи. Интересите му обхващат разработка на уеб приложения, приложения с бази от данни, изграждане на сървърни системи и участие в академични дейности.

Моника Алексиева

Моника Алексиева е софтуерен разработчик във фирма Солвер / Мидакс (www.midax.com). В момента следва специалност информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Моника има професионален опит в разработката за .NET Framework с езика C# и е сертифициран от Microsoft разработчик за .NET платформата. Нейните интереси са в областта на технологиите за изграждането на графичен потребителски интерфейс и разработката на приложения за мобилни устройства. През 2004 година Моника е асистент по "Структури от Данни" в Софийски университет.

Николай Недялков

Николай Недялков е президент на Асоциацията за информационна сигурност (www.iseca.org) която е създадена с цел прилагане на най-добрите практики за осигуряване на информационната сигурност на национално ниво и при извършването на електронен бизнес. Николай е професионален разработчик на софтуер, консултант и преподавател с дългогодишен опит. Той е автор на статии и лектор на множество конференции и семинари в областта на софтуерните технологии и информационна сигурност. Преподавателският му опит се простира от асистент по "Структури от данни в програмирането", "Обектно-ориентирано програмиране със C++" и "Visual C++" до лектор в курсовете "Мрежова сигурност", "Сигурен програмен код", "Интернет програмиране с Java", "Конструиране на качествен програмен код", "Програмиране за платформа .NET" и "Разработка на приложения с Java". Интересите на Николай са концентрирани върху техническата и бизнес страната на информационната сигурност, Java и .NET технологиите и моделирането и управлението на бизнес процеси в големи организации. Николай има бакалавърска степен от Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Като ученик е дългогодишен състезател по програмиране, с редица призови отличия. През 2004 г. е награден от Президента на България Георги Първанов за приноса му към развитието на информационните технологии и информационното общество. Той е почетен член на БАРС. Личният му сайт е достъпен от адрес: www.nedyalkov.com.

Панайот Добриков

Панайот Добриков е софтуерен архитект в SAP A.G., Java Server Technology (www.sap.com), Германия и е отговорен за координацията на софтуерните разработки в SAP Labs България. Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Панайот е дългогодишен участник (като състезател и ръководител) в ученически и студентски състезания по програмиране и е носител на много престижни награди в страната и чужбина. Той е автор на книгите "Програмиране = ++Алгоритми;" (www. algoplus.org) и "Java Programming with SAP Web Application Server", както и на десетки научно-технически публикации. През периода 2001-2003 води курсовете "Проектиране и анализ на компютърни алгоритми" и "Прагматика на обектното програмиране" в Софийски университет. Можете да се свържете с Панайот по e-mail: dobrikov@gmail.com.

Преслав Наков

Преслав Наков е аспирант по изкуствен интелект в Калифорнийския университет в Бъркли (www.berkeley.edu), САЩ. Неговият професионален опит включва шестгодишна работа като софтуерен разработчик във фирмите Комсофт (www.comsoft.bg) и Рила Солюшънс (www.rila.bg). Интересите му са в областта на компютърната лингвистика и биоинформатикатa. Преслав получава магистърската си степен по информатика от Софийски университет "Св. Климент Охридски". Той е носител е на бронзов медал от Балканиада по информатика, заемал призови места в десетки национални състезания по програмиране като ученик и студент. Състезател е, а по-късно и треньор на отбора на Софийския университет, участник в Световното междууниверситетско състезание по програмиране (ACM International Collegiate Programming Contest). Той е асистент в множество курсове във Факултета по математика и информатика на Софийски университет, лектор-основател на курсовете "Проектиране и анализ на компютърни алгоритми" и "Моделиране на данни и проектиране на бази от данни". Преслав е автор на книгите "Основи на компютърните алгоритми" и "Програмиране = ++Алгоритми;" (www.algoplus.org). Той има десетки научни и научнопопулярни публикации в престижни международни и национални издания. Той е първият носител на наградата "Джон Атанасов" за принос към развитието на информационните технологии и информационното общество, учредена от президента на България Георги Първанов.

Радослав Иванов

Радослав Иванов е софтуерен разработчик във фирма Медсофт (www. medsoft.biz) и студент в специалност информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Професионалните му интереси са в областта на информационната сигурност и продуктите и технологиите на Microsoft.

Рослан Борисов

Рослан Борисов е софтуерен инженер във фирма Сирма Груп (www.sirma.bg), звено на Сирма Бизнес Консултинг. Професионалните му интереси са свързани основно с изграждане на приложения, базирани на технологии на Microsoft. Специализирал е в областта на билинг системи, като и основни и сателитни банкови системи. Има сериозен опит с платформата .NET Framework и сървърите за бази от данни Microsoft SQL Server и Oracle. Участва в различни проекти, свързани с български и чужди банки. В момента Рослан е студент в Нов български университет, специалност информатика. Можете да се свържете с него на e-mail: rosborisov@gmail.com.

Светлин Наков

Светлин Наков е директор на направление "обучение" на Националната академия по разработка на софтуер (http://academy.devbg.org), където обучава софтуерни специалисти за практическа работа в ИТ индустрията с Java и .NET платформите. Той е хоноруван преподавател по съвременни софтуерни технологии в Софийски университет "Св. Климент Охридски", където води курсове по "Проектиране и анализ на компютърни алгоритми", "Интернет програмиране с Java", "Мрежова сигурност", "Програмиране за .NET Framework", "Качествен програмен код" и "Разработка на уеб приложения с Java". Светлин има сериозен професионален опит като софтуерен разработчик и консултант. Неговите интереси обхващат Java технологиите, .NET платформата и информационната сигурност. Той е завършил бакалавърската и магистърската си степен във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Като ученик и студент Светлин е победител в десетки национални състезания по програмиране и е носител на 4 медала от международни олимпиади по информатика. Той има десетки научни и технически публикации, свързани с разработката на софтуер, в български и чуждестранни списания и е автор на книгите "Интернет програмиране с Java", "Java за цифрово подписване на документи в уеб" и ръководител на двата тома на настоящата книга. През 2003 г. той е носител на наградата "Джон Атанасов" на фондация Еврика. През 2004 г. получава награда "Джон Атанасов" от президента на България Георги Първанов за приноса му към развитието на информационните технологии и информационното общество. Светлин е един от учредителите на Българската асоциация на разработчиците на софтуер (www.devbg.org) и понастоящем неин председател.

Стефан Добрев

Стефан Добрев е старши уеб разработчик във фирма Vizibility (www.vizibility.net). Той отговаря за голяма част от .NET продуктите, разработвани в софтуерната компания, в това число уеб базирана система за изграждане на динамични сайтове и управление на тяхното съдържание, уеб система за управление на контакти и др. Негова отговорност е и внедряването на утвърдените практики и методологии за разработка на софтуер в производствения процес. Професионалните му интереси са насочени към уеб технологиите, в частност ASP.NET, XML уеб услугите и цялостната разработка на приложения, базирани на .NET Framework. Стефан следва информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски".

Стефан Кирязов

Стефан Кирязов е софтуерен разработчик във фирма Верео Технолъджис (www.vereo.bg). Той се занимава професионално с разработка на .NET решения за бизнеса и държавната администрация. Опитът му включва изграждане на уеб и настолни приложения с технологии на Microsoft, а също и Java и Oracle. Завършил е Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Неговите професионални интереси включват архитектура, дизайн и методологии за разработка на големи корпоративни приложения. За контакти със Стефан можете да използвате неговия e-mail: stefan.kiryazov@gmail.com.

Стефан Захариев

Стефан Захариев работи като софтуерен разработчик в Интерконсулт България (www.icb.bg), където е отговорен за създаването на инструменти за автоматизиране на процеса на разработка. Той има дългогодишен опит в създаването на ERP системи, който натрупва при работата си в различни фирми в България. Основните му интереси са свързани със системите за управление на бази от данни, платформата .NET, ORM инструментите, J2ME, както и Borland Delphi. При завършването си на средното образование в "Технологично училище – Електронни системи", печели отличителна награда за цялостни постижения. През 2005 г. завършва "Технически университет – София", където се дипломира като бакалавър във факултета по "Компютърни системи и управление". Той членува в БАРС и в Софийската .NET потребителска група Можете да се свържете със Стефан по e-mail: stephan.zahariev@gmail.com.

Стоян Дамов

Стоян Дамов е софтуерен консултант, пич, поет и революционер. Можете да се свържете с него по e-mail: stoyan.damov@gmail.com или от неговия личен сайт: http://spaces.msn.com/members/stoyan/.

Тодор Колев

Тодор Колев е софтуерен разработчик в Gugga (www.gugga.com) и студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност Информатика. Неговите професионални интереси са в областта на обектно-ориентирания анализ, моделиране и програмиране, уеб технологиите, базите данни и RIA (Rich Internet Applications). Тодор е дългогодишен участник в състезания по информатика и информационни технологии, печелил редица грамоти и отличия, както и сребърен медал на международна олимпиада по информационни технологии. Той е носител на първо място от националната олимпиада по информационни технологии и е участвал в журито на същата олимпиада година по-късно. Тодор има множество разработки в сферата на уеб технологиите и е участвал в изследователски екип в Масачузетският технологичен институт (MIT). Той е сертифициран Microsoft специалист.

Христо Дешев

Христо Дешев е разработчик на ASP.NET компоненти във фирма telerik (www.telerik.com). Той е завършил Американския университет в България, специалност информатика. Основните му интереси са в областта на подобряването на процеса на разработка на софтуер. Той е запален привърженик на Agile методологиите, основно на Extreme Programming (XP). Професионалният му опит е предимно в разработката на решения с кратък цикъл за обратна връзка, високо покритие от тестове и почти пълна автоматизация на всички нива от работния процес.

Христо Радков

Христо Радков е управител на фирма за софтуерни консултантски услуги Calisto ID (www.calistoid.com). Той е бакалавър от английската специалност "Manufacturing Engineering" в Технически Университет – София и магистър по информационни и комуникационни технологии във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Притежава сертификационна степен от Microsoft - MCSD.NET. Христо има дългогодишен опит с различни сървъри за бази от данни и сериозен опит с различни технологии на Microsoft, Borland, Sun и Oracle. Участник и ръководител е в проекти за изграждане на няколко големи информационни системи, динамични Интернет портали и др. Под негово ръководство е създаден най-успешния складово-счетоводен софтуер за фармацевтични предприятия в страната. Като ученик Христо има множество участия и награди от олимпиади по математика в страната и чужбина.

Цветелин Андреев

Цветелин Андреев е софтуерен инженер във фирма Dreamix Ltd. (www.dreamix.eu). Той е член на Българската асоциация на разработчиците на софтуер и е инструктор към Националната академия по разработка на софтуер. Цветелин участва като лектор в редица курсове и семинари. Изявява се и като консултант по използване на модерни уеб технологии. Част от интересите му са свързани с платформата FreeBSD, в частност използването й за разработка на софтуер. Член е на групата на българските потребители на FreeBSD (freebsd-bg.org). Цветелин е завършил бакалавърска степен по информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", а сега е студент по Стопанско Управление в същия университет. Личният му уеб сайт е достъпен от адрес: www.flowerlin.net.

Явор Ташев

Явор Ташев е софтуерен разработчик във фирма ComMetric (www. commetric.com). Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Участвал е в разработката на големи корпоративни сайтове, комуникационни системи и решения за обработка на статистически данни и прогнозиране с методи на изкуствен интелект, използвайки технологиите и платформите на Microsoft. Интересите му са насочени към .NET платформата, Java и изкуствения интелект. Професионалният му опит е свързан предимно с .NET Framework, Visual Studio .NET, Microsoft SQL Server и Microsoft Internet Information Server.

Благодарности

Настоящата книга стана реалност благодарение на много хора и няколко организации, които помогнаха и допринесоха за проекта. Нека изкажем своята благодарност и уважение към тях.

Светлин Наков

На първо място трябва да благодарим на главния организатор и ръководител на проекта, Светлин Наков, който успя да мотивира над 30 души да участват в начинанието и успя да ги ръководи успешно през всичките месеци на работата по проекта. Той успя да реализира своята идея за създаване на чисто българска книга за програмиране с .NET Framework най-вече благодарение на всички доброволни участници, които дариха своя труд за проекта и отделиха от малкото си свободно време за да споделят своите знания и опит безвъзмездно, за каузата.

Авторският колектив

Авторският колектив е наистина главният виновник за съществуването на тази книга. Текст с такъв обем и такова качество не може да бъде написан от един или двама автора за по-малко от няколко години, а до тогава информацията може вече да остаряла.

Идеята за участие на толкова много автори се оказа успешна, макар и координацията между тях да не беше лесна. Въпреки, че отделните глави от книгата са писани от различни автори, те следват единен стил и високо качество. Всички глави са добре структурирани, с много заглавия и подзаглавия, с много и подходящи примери, с добър стил на изказ и еднакво форматиране.

Българска асоциация на разработчиците на софтуер

Проектът получи силна подкрепа от Българската асоциация на разработчиците на софтуер (БАРС), тъй като е в синхрон с нейните цели и идеи.

БАРС официално държи правата за издаване и разпространение на книгата в хартиен вид, но няма право да реализира печалба от тази дейност. Асоциацията чрез своите контакти успя да намери финансиране за отпечатването на книгата, както и хостинг за нейния уеб сайт и форум.

Microsoft Research

В ранните си фази, когато бяха изготвени лекциите за курса "Програмиране за .NET Framework", проектът получи подкрепа и частично финансиране от Microsoft Research. Ако не беше тази подкрепа, вероятно нямаше да се стигне до създаването на лекциите и до написването на книгата.

SciForge.org

Порталът за организиране на работата в екип SciForge.org даде своя принос към проекта, като предостави среда за съвместна работа, включваща система за контрол над версиите, форум, пощенски списък (mailing list) и някои други средства за улеснение на работата.

Благодарностите са отправени главно към създателя на портала и негов главен администратор Калин Наков (www.kalinnakov.com), който указваше редовно съдействие в случай на технически проблеми.

Софийски университет "Св. Климент Охридски"

Факултетът по математика и информатика (ФМИ) на Софийски университет "Св. Климент Охридски" подпомогна проекта главно в началната му фаза, като подкрепи предложението на преподавателския екип от курса "Програмиране за платформа .NET" за участие в конкурса на Microsoft Research. По-късно факултетът продължи да подкрепя инициативите на авторския колектив на книгата като им позволи да провеждат изборни курсове по програмиране за .NET Framework 1.1 и 2.0 за студентите от Софийски университет.

telerik

Софтуерната компания telerik (www.telerik.com) подкрепи проекта чрез осигуряване на финансиране за отпечатване на книгата на хартия. Изказваме благодарности от името на целия авторски колектив.

Сайтът на книгата

Официалният уеб сайт на книгата "Програмиране за .NET Framework" е достъпен от адрес: http://www.devbg.org/dotnetbook/. От него можете да изтеглите цялата книга в електронен вид, лекциите, на които тя е базирана, както и сорс кода на практическия проект от глава 29, за който има специално изготвена инсталираща програма.

Към книгата е създаден и дискусионен форум, който се намира на адрес: http://www.devbg.org/forum/index.php?showforum=30. В него можете да дискутирате всякакви технически и други проблеми, свързани с книгата, да отправяте мнения и коментари и да задавате въпроси към авторите.

Лиценз

Книгата и учебните материали към нея се разпространяват свободно по следния лиценз:

Общи дефиниции

1. Настоящият лиценз дефинира условията за използване и разпространение на комплект учебни материали и книга по "Програмиране за .NET Framework", разработени от екип под ръководството на Светлин Наков (www.nakov.com) с подкрепата на Българска асоциация на разработчиците на софтуер (www.devbg.org) и Microsoft Research (research.microsoft.com).

2. Учебните материали се състоят от:

- презентации;

- примерен сорс код;

- демонстрационни програми;

- задачи за упражнения;

- книга (учебник) по програмиране за .NET Framework с езика C#.

3. Учебните материали са достъпни за свободно изтегляне при условията на настоящия лиценз от официалния сайт на проекта:

http://www.devbg.org/dotnetbook/

4. Автори на учебните материали са лицата, взели участие в тяхното изработване. Всеки автор притежава права само над продуктите на своя труд.

5. Потребител на учебните материали е всеки, който по някакъв начин използва тези материали или части от тях.

Права и ограничения на потребителите

1. Потребителите имат право:

- да използват учебните материали или части от тях за всякакви цели, включително да ги да променят според своите нужди и да ги използват при извършване на комерсиална дейност;

- да използват сорс кода от примерите и демонстрациите, включени към учебните материали или техни модификации, за всякакви нужди, включително и в комерсиални софтуерни продукти;

- да разпространяват безплатно непроменени копия на учебните материали в електронен или хартиен вид;

- да разпространяват безплатно оригинални или променени части от учебните материали, но само при изричното споменаване на източника и авторите на съответния текст, програмен код или друг материал.

2. Потребителите нямат право:

- да разпространяват срещу заплащане учебните материали или части от тях (включително модифицирани версии), като изключение прави само програмният код;

- да премахват настоящия лиценз от учебните материали.

Права и ограничения на авторите

1. Всеки автор притежава неизключителни права върху продуктите на своя труд, с които взима участие в изработката на учебните материали.

2. Авторите имат право да използват частите, изработени от тях, за всякакви цели, включително да ги изменят и разпространяват срещу заплащане.

3. Правата върху учебните материали, изработени в съавторство, са притежание на всички съавтори заедно.

4. Авторите нямат право да разпространяват срещу заплащане учебни материали или части от тях, изработени в съавторство, без изричното съгласие на всички съавтори.

Права и ограничения на БАРС

Ръководството на Българска асоциация на разработчиците на софтуер (БАРС) има право да разпространява учебните материали или части от тях (включително модифицирани) безплатно или срещу заплащане, но без да реализира печалба от продажби.

Права и ограничения на Microsoft Research

Microsoft Research има право да разпространява учебните материали или части от тях по всякакъв начин – безплатно или срещу заплащане, но без да реализира печалба от продажби.

Светлин Наков,

01.11.2006 г.

Глава 15. Изграждане на графичен потребителски интерфейс с Windows Forms

Автори

Светлин Наков

Радослав Иванов

Необходими знания

- Базови познания за .NET Framework

- Базови познания за езика C#

- Базови познания за делегатите и събитията в .NET Framework

- Начални умения за работа с Visual Studio .NET и Windows Forms редактора му

Съдържание

- Какво е Windows Forms?

- Програмни компоненти. Компонентен модел на .NET

- Програмен модел на Windows Forms. Модел на пречертаване на контролите

- Основни класове. Йерархия на класовете

- Класът Control. Други базови контроли

- Форми, прозорци и диалози – класът Form

- Основни контроли – TextBox, Label, Button

- Поставяне на контроли във формата

- Управление на събитията

- Windows Forms редакторът на VS.NET

- Стандартни диалогови кутии

- Извикване на диалогови кутии

- Други Windows Forms контроли. Менюта. Ленти с инструменти. Статус ленти

- Диалог за избор на файл

- MDI приложения

- Валидация на данни

- Свързване на данни (Data Binding). Навигация с CurrencyManager

- Контролата DataGrid

- Master-Details навигация

- Наследяване на форми

- Пакетът System.Drawing и GDI+

- Печатане на принтер

- Потребителски контроли

- Хостинг на контроли в Internet Explorer

- Нишки и Windows Forms

- Влачене (Drag and Drop)

- Конфигурационен файл на приложението

В тази тема ...

В настоящата тема ще разгледаме средствата на Windows Forms за създаване на прозоречно-базиран графичен потребителски интерфейс (GUI) за .NET приложенията. Ще се запознаем с програмния модел на Windows Forms, неговите базови контроли, средствата за създаване на прозорци, диалози, менюта, ленти с инструменти и статус ленти, както и с някои по-сложни концепции: MDI приложения, data-binding, наследяване на форми, хостинг на контроли в Internet Explorer, работа с нишки в Windows Forms и др.

Какво е Windows Forms?

Windows Forms е стандартната библиотека на .NET Framework за изграждане на прозоречно-базиран графичен потребителски интерфейс (GUI) за настолни (desktop) приложения. Windows Forms дефинира набор от класове и типове, позволяващи изграждане на прозорци и диалози с графични контроли в тях, чрез които се извършва интерактивно взаимодействие с потребителя.

При настолните приложения графичният потребителски интерфейс позволява потребителят директно да взаимодейства с програмата чрез мишката и клавиатурата, а програмата прихваща неговите действия и ги обработва по подходящ начин.

Windows Forms е базирана на RAD концепцията

В .NET Framework и особено в Windows Forms се поддържа концепцията за Rapid Application Development (RAD).

Какво е RAD?

RAD е подход за разработка, при който приложенията се създават визуално чрез сглобяване на готови компоненти посредством помощници и инструменти за автоматично генериране на голяма част от кода. В резултат приложенията се разработват много бързо, с малко ръчно писане на код и с намалени усилия от страна на програмиста.

При компонентно-ориентираната разработка всеки компонент решава някаква определена задача, която е част от проекта. Компонентите се поставят в приложението, след което се интегрират един с друг чрез настройка на техните свойства и събития. Свойствата на всеки компонент определят различни негови характеристики, а събитията служат за управление на действията, които са предизвикани от него.

Windows Forms позволява бърза визуална разработка

Windows Forms е типична компонентно-ориентирана библиотека за създаване на GUI, която предоставя възможност с малко писане на програмен код да се създава гъвкав графичен потребителски интерфейс.

Windows Forms позволява създаването на формите и другите елементи от графичния интерфейс на приложенията да се извършва визуално и интуитивно чрез подходящи редактори, като например Windows Forms Designer във Visual Studio .NET. По-нататък в настоящата тема ще разгледаме по-подробно конкретните възможности, които VS.NET предоставя за създаване на Windows Forms приложения.

Windows Forms и другите библиотеки за изграждане на GUI

Windows Forms прилича на много други библиотеки за изграждане на графичен потребителски интерфейс (GUI), но и сериозно се различава от повечето от тях.

Windows Forms и VCL

На идейно ниво Windows Forms много прилича на библиотеката Visual Component Library (VCL) от Delphi. Приличат си в голяма степен дори самите контроли, техните имена, свойства и събития. Това вероятно се дължи до голяма степен на участието на главния архитект на Delphi Андерс Хейлсбърг в разработката на Windows Forms и .NET Framework.

Windows Forms и Visual Basic 6

По начина на разработка Windows Forms прилича много и на Visual Basic 6, който позволява визуално изграждане на интерфейса, чрез влачене на компоненти и настройка на свойства и събития, също както в Delphi.

Windows Forms и MFC

По своята мощ Windows Forms не отстъпва на по-старите средства за изграждане на GUI, например MFC (Microsoft Foundation Classes) библиотеката, която се използваше във Visual C++ преди Microsoft да вземат стратегическото решение разработката на GUI за Windows да преминава постепенно към .NET Framework и Windows Forms.

За разлика от MFC, при Windows Forms, интерфейсът се изгражда няколко пъти по-бързо, по-лесно и почти без да се пише програмен код.

Windows Forms и Java AWT/Swing

AWT и Swing са библиотеки за изграждане на прозоречно-базиран GUI, които се използват при Java платформата. Програмният модел на Windows Forms има съществени разлики от програмния модел на AWT и Swing и причините за това произхождат най-вече от факта, че AWT и Swing са преносими библиотеки, предназначени да работят на много операционни системи, докато Windows Forms е базирана на Win32 API.

Контролите в Windows Forms

Windows Forms съдържа богат набор от стандартни контроли: форми, диалози, бутони, контроли за избор, текстови полета, менюта, ленти с инструменти, статус ленти и много други. В допълнение към стандартните контроли Windows Forms позволява на разработчиците по лесен начин да създават допълнително собствени контроли, които да използват като части в приложенията си.

В Интернет могат да се намерят безплатно или срещу лицензна такса голям брой библиотеки от контроли, които решават често срещани проблеми и спестяват време на разработчика при реализацията на често срещани задачи. Съществуват дори цели софтуерни компании, които професионално се занимават с производството на компоненти и контроли (като Infragistics, ComponentOne и българската telerik).

Windows Forms и работа с данни

Windows Forms предоставя много контроли за визуализация и редактиране на данни – текстови, списъчни и таблични. За спестяване на време на разработчика е въведена концепцията "свързване на данни" (data binding), която позволява автоматично свързване на данните с контролите за тяхната визуализация. Ще обърнем специално внимание на концепцията "data binding" по-късно в настоящата тема.

Вградена поддръжка на Unicode

В Windows Forms поддръжката на Unicode е вградена. Всички контроли са съобразени с Unicode стандарта и позволяват използване на много езици и азбуки (латиница, кирилица, гръцки, арабски и др.) без допълнителни настройки на Windows или на приложението.

Наследяване на форми и контроли

Windows Forms е проектирана така, че да позволява лесно наследяване и разширяване на форми и контроли. Това дава възможност за преизползване на общите части на потребителския интерфейс. По-нататък в настоящата тема ще демонстрираме как точно се реализира това.

ActiveX контроли

Преди появата на .NET Framework Windows приложенията са били базирани на програмния модел "Win32". В Win32 среда се използват т. нар. ActiveX контроли, които се реализират чрез компонентния модел на Windows (COM – Component Object Model).

ActiveX контролите представляват графични компоненти. Те имат свойства, чрез които им се задават различни характеристики, и събития, управляващи поведението им.

ActiveX контролите много приличат на Windows Forms контролите от .NET Framework, но за разлика от тях се реализират с неуправляван код и преди използване трябва да се регистрират чрез добавяне в регистрите на Windows (Windows Registry).

Поради дългия период на развитие на Win32 платформата, има изключително много ActiveX контроли, които са създадени с течение на годините от различни софтуерни производители.

В .NET Framework по лесен начин, без да се пише ръчно програмен код, могат да се използват вече разработени ActiveX контроли. Например можем да вградим уеб браузъра Internet Explorer или четеца на PDF документи Adobe Acrobat Reader като част от наше приложение. Как точно се използват ActiveX контроли в Windows Forms ще разгледаме в темата "Взаимодействие с неуправляван код".

Печатане на принтер

В Windows Forms са предоставени удобни средства за печатане на документи на принтер. Те предоставят достъп до всички стандартни диалози за печат, чрез които потребителите избират печатащо устройство и настройват неговите характеристики. Самото печатане се извършва със стандартните средства на .NET Framework за чертане върху повърхности.

Windows Forms контроли в Internet Explorer

При проектирането на .NET Framework е заложено Windows Forms контролите да могат да се изпълняват в средата на Internet Explorer или други уеб браузъри, без да се застрашава сигурността на потребителя.

Тази технология е една добра съвременна алтернатива на Java аплетите и позволява разширяване на функционалността на уеб приложенията с гъвкав интерактивен потребителски интерфейс. На практика се дава възможност .NET приложения да се изпълняват в браузъра на клиента като се вградят в най-обикновена уеб страница (подобно на Flash технологията).

Силна поддръжка на графика (GDI+)

Библиотеката Windows Forms широко използва средствата на Windows платформата за чертане и работа с графични обекти (GDI+). Windows Forms позволява тези средства да се използват за създаване на собствени изображения върху различни повърхности – в прозорец, върху принтер, плотер и др. Дава се достъп до всички по-важни примитиви за чертане –текст, графични изображения, геометрични фигури (точки, линии, правоъгълници, елипси) и т. н.

Нашето първо Windows Forms приложение

За да илюстрираме как се използва на практика Windows Forms, да разгледаме следното просто приложение:

using System;

using System.Windows.Forms;

public class SampleForm : System.Windows.Forms.Form

{

static void Main()

{

SampleForm sampleForm = new SampleForm();

sampleForm.Text = "Sample Form";

Button button = new Button();

button.Text = "Close";

button.Click +=

new EventHandler(sampleForm.button_Click);

sampleForm.Controls.Add(button);

sampleForm.ShowDialog();

sampleForm.Dispose();

}

private void button_Click(object sender, EventArgs e)

{

Close();

}

В него се създава прозорец, който съдържа бутон с текст "Close". При натискане на бутона прозорецът се затваря (това се реализира чрез прихващане и обработка на събитието "натискане на бутона").

Как да компилираме и стартираме примера?

За да компилираме горното приложение, можем да ползваме конзолния компилатор на .NET Framework за езика C#:

csc SampleForm.cs

Можем да компилираме примера и от VS.NET, но за целта трябва да създадем нов Windows Application проект и да копираме кода в него.

При изпълнение на приложението се получава следния резултат:

Как работи примерът?

Нашето първо Windows Forms приложение е доста просто. То е изградено по следния начин:

- Дефиниран е клас SampleForm, който наследява класа System. Windows.Forms.Form. Този клас представлява главната форма на приложението.

- В главния метод Main() първо се задава заглавие за формата. След това се създава бутон, който се добавя в списъка с контролите на формата и се прихваща събитието "щракване върху бутона". Накрая формата се показва в модален режим (модален режим означава, че другите форми на приложението не са активни, докато не се затвори текущата) и след затварянето й се унищожава.

- При натискане на бутона се извиква събитие, което затваря формата, и приложението завършва.

Примерът е доста прост и показва основните моменти при изграждането на потребителски интерфейс с Windows Forms – създаване на форми, поставяне на контроли във формите, настройка на свойствата на контролите, прихващане и обработване на събития.

Библиотеките на .NET за изграждане на GUI

Средствата на .NET Framework за изграждане на графичен потребителски интерфейс са дефинирани в пространствата от имена System.Drawing и System.Windows.Forms, които са реализирани съответно в асемблитата System.Drawing.dll и System.Windows.Forms.dll. Тези пространства заедно с пространствата, съдържащи се в тях, са изобразени на фигурата:

Пространството System.Windows.Forms

Класовете и типовете от пространството System.Windows.Forms осигуряват средства за работа с прозорци, диалози, контроли за въвеждане на текст, контроли за избор, менюта, ленти с инструменти, таблици, дървета и др.

Пространството System.Windows.Forms.Design

Пространството System.Windows.Forms.Design съдържа класове, които поддържат конфигурирането на компонентите и дефинират поведението на Windows Forms контролите по време на дизайн.

Пространството System.Drawing

Класовете и типовете от пространството System.Drawing и неговите подпространства осигуряват достъп до GDI+ функциите на Windows: работа с повърхности, точки, линии, четки, моливи, геометрични фигури, картинки, текст и шрифтове и др.

Програмни компоненти

В софтуерното инженерство компонентите са преизползваеми (reusable) програмни единици (класове), които решават специфична задача. Всеки компонент има ясно дефиниран интерфейс, който описва неговите свойства, методи и събития. Компонентите се използват като части от други компоненти или програми – те са градивните елементи на софтуера.

Компонентен модел

В софтуерното инженерство компонентният модел дефинира стандартите за разработка и използване на програмните компоненти и техния жизнен цикъл. Тези стандарти описват чрез интерфейси модела на поведение и взаимодействие на всички компоненти в дадена среда.

Компонентният модел на .NET Framework

Компонентният модел на .NET Framework дефинира програмния модел (система от правила) за създаване и използване на .NET компоненти. Този програмен модел се реализира чрез определени класове и интерфейси, които поддържат описанието на компонентите.

В .NET Framework компонентният модел позволява дефиниране на поведението на компонентите по време на дизайн (design-time behavior) и по време на работа (runtime behavior).

Компоненти и контейнери

В .NET Framework са дефинирани два вида преизползваеми обекти: компоненти и контейнери. Компонентите са функционални единици, които решават някаква задача, а контейнерите са обекти, които съдържат списък от компоненти.

Преизползваемост на компонентите

Благодарение на междуезиковата съвместимост, която CLR осигурява, .NET компонентите могат директно да се преизползват във всички .NET езици за програмиране. Възможно е .NET компоненти да бъдат използвани и от Win32 приложения, но за целта трябва да се публикуват във вид на COM обекти.

Пространството System.ComponentModel

Компоненти се използват не само в Windows Forms, а навсякъде в .NET Framework. По тази причина основната функционалност на компонентния модел на .NET се намира в пространството System.ComponentModel. В него са дефинирани основните интерфейси IComponent и IContainer и техните имплементации Component и Container.

Windows Forms и компонентният модел на .NET

В архитектурата на Windows Forms залягат концепциите на компонентния модел на .NET Framework. Компонентният модел на .NET дефинира компоненти и контейнери. По подобен начин Windows Forms дефинира контроли и контейнер-контроли.

Контроли и контейнер-контроли

Контролите в Windows Forms са всички компоненти, които са видими за потребителя (имат графично изображение). Те биват два вида: контейнер контроли (форми, диалози, панели и т.н.) и контроли (бутони, текстови полета, етикети, списъчни контроли и т.н.). Контейнерите са предназначени да съдържат в себе си други контроли (включително и други контейнер контроли), докато контролите са предназначени да се съдържат в контейнер контролите.

В Windows Forms всяка контрола може да се използва като контейнер-контрола, но за някои контроли това е безсмислено. Няма смисъл и не е правилно в бутон да се поставят други бутони или текстови полета.

Програмен модел на Windows Forms

Програмният модел на Windows Forms дефинира класовете за работа с форми, диалози и контроли, събитията на контролите, жизнения цикъл на приложенията, модела на пречертаване на контролите, модела на получаване и обработка на събитията и модела на управление на фокуса. Нека разгледаме всички тези елементи от програмния модел.

Форми

Windows Forms предлага стандартни класове за работа с форми (това са прозорците и диалозите в GUI приложенията). Формите могат да бъдат модални и немодални (по една или по много активни едновременно). Формите са контейнер-контроли и могат да съдържат други контроли, например етикети, текстови полета, бутони и т.н. Базов клас за всички форми е класът System.Windows.Forms.Form.

Контроли

Контролите в Windows Forms са текстовите полета, етикетите, бутоните, списъците, дърветата, таблиците, менютата, лентите с инструменти, статус лентите и много други. Windows Forms дефинира базови класове за контролите и класове-наследници за всяка контрола. Базов клас за всички контроли е класът System.Windows.Forms.Control. Пример за контрола е например бутонът (класът System.Windows.Forms.Button).

Събития

Всички контроли от Windows Forms дефинират събития, които програмистът може да прихваща. Например контролата Button дефинира събитието Click, което се активира при натискане на бутона. Събитията в Windows Forms управляват взаимодействието между програмата и контролите и между самите контроли.

Жизнен цикъл на Windows Forms приложенията

Жизненият цикъл на GUI приложенията е базиран на съобщения. Графичната среда на операционната система прихваща всички потребителски действия (напр. движението на мишката, натискането на клавиши от клавиатурата и т.н.) и ги натрупва в специална опашка. След това всяко съобщение се предава към приложението, за което се отнася и по-точно към нишката (thread) от приложението, за която се отнася.

Нишки и многозадачност

В многозадачните операционни системи (каквито са например Windows и Linux) е възможно едно приложение да изпълнява няколко задачи паралелно, като използва няколко нишки (threads) в рамките на процеса, в който работи програмата.

За целите на настоящата тема можем да си мислим, че нишките са нещо като отделни задачи в програмата, които се изпълняват едновременно (паралелно) в даден момент. По-нататък, в темата "Многонишково програмиране и синхронизация", ще обърнем специално внимание на многозадачността, използването и синхронизацията на нишки.

Опашката от събития

Всяка нишка от всяко приложение си има своя собствена опашка, в която постъпват съобщенията за всички събития, идващи от потребителя или от други източници. Всяко съобщение носи информация за събитието, което е настъпило – часът на настъпване, идентификатор на прозорец, за който се отнася събитието, тип на събитието, параметри на събитието (напр. номер на натиснатия клавиш при събитие от клавиатурата или позиция на курсора при събитие от мишката) и т.н. В Windows Forms съобщенията са инстанции на структурата System.Windows.Forms.Message.

Главната нишка на всяко Windows Forms приложение извършва една единствена задача: в безкраен цикъл обработва опашката от съобщения за приложението и предава постъпилите съобщения на контролата, за която са предназначени.

В Windows Forms приложенията винаги имат точно една нишка, която обработва всички съобщения, идващи от графичните контроли, и това е главната нишка на приложението. Графичният потребителски интерфейс на цялото приложение се управлява от тази нишка. При настъпване на събитие, свързано с някоя от формите на приложението или контролите в нея, в опашката на главната нишка постъпва съответно съобщение и то се обработва, когато му дойде редът.

Само главната нишка трябва да взаимодейства с опашката от събития

Много е важно, когато разработваме Windows Forms приложения, да се съобразяваме със следното правило:

Графичният потребителски интерфейс на приложението трябва да се управлява само и единствено от неговата главна нишка.

Ако не спазваме това правило, ще се сблъскаме с много странни и неприятни проблеми. Например, ако стартираме едновременно няколко нишки и от всяка от тях от време на време променяме съдържанието на определено текстово поле, е възможно в дадени моменти приложението да "зависва".

Всяка контрола обработва собствените си събития

Когато главната нишка на Windows Forms приложение получи съобщение, свързано с някоя от неговите форми, тя препраща съобщението до обработчика на съобщения на съответната форма. Този обработчик от своя страна проверява дали съобщението е за самата форма или за някоя нейна контрола. Ако съобщението е за формата, то се обработва директно от съответния обработчик на събития. Ако съобщението е за някоя от контролите във формата, то се предава на нея. Контролата, която получи съобщението, може да е обикновена контрола или контейнер-контрола. Когато обикновена контрола получи съобщение, тя го обработва директно. Когато контейнер-контрола получи съобщение, тя проверява дали то е за нея или е за някоя от вложените контроли. Процесът продължава, докато съобщението достигне до контролата, за която е предназначено.

По описаната схема всяко съобщение преминава от главната нишка на приложението през формата, за която се отнася, и евентуално през още една или няколко други контроли, докато си намери обработчика.

Обработка на събитие – пример

Нека имаме някакво приложение, което се състои от една форма, в която има един бутон. Да предположим, че натиснем левия бутон на мишката, докато курсорът е върху бутона във формата. Какво се случва?

Главната нишка на приложението получава съобщение "натиснат ляв бутон на мишка", в което са записани координатите, в които е бил курсорът на мишката в момента на натискането. Операционната система подава тези координати относително спрямо горния ляв ъгъл на формата.

Докато обработва съобщението, главната нишка на приложението открива формата, за която се отнася събитието (това е най-горната от всички форми, в които попада курсорът на мишката) и го предава на нейния обработчик на събития.

Формата получава съобщението и вижда, че то се отнася за някаква позиция, в която се намира някаква нейна контрола (в случая това е бутонът). Формата преценява, че съобщението не е за нея, а е за бутона, и му го предава.

Бутонът получава събитието и вижда, че то е предназначено точно за него. Събитието бива погълнато (консумирано) от обработчика на събития на бутона и съответно бутонът преминава в състояние "натиснат". Самият бутон малко след това изпраща събитие за пречертаване до самия себе си (на пречертаването ще обърнем внимание след малко). Когато това събитие достигне по същия път до бутона, той се пречертава в натиснато състояние.

Прекратяване на Windows Forms приложение

При затваряне на главната форма на Windows Forms приложение, към нея се изпраща съобщение за затваряне. Формата се затваря в момента, в който получи съобщението и го обработи. В резултат на затварянето на формата се прекратява цикълът, в който главната нишка на приложението обработва пристигащите за нея съобщения и приложението приключва изпълнението си.

Модел на пречертаване на контролите

В Windows Forms контролите често се пречертават, например при преместване на прозорец, при смяна на активния прозорец или при промяна на размера, позицията или състоянието на някоя контрола. При всяко от изброените действия една или няколко контроли, които попадат в обсега на даден засегнат регион, се обявяват за невалидни и се активира процесът на пречертаване.

Процесът на пречертаване

Процесът на пречертаване на контрола, която е засегната от промяна в нея самата, от промяна на контейнер-контролата, в която се намира, или от промяна в други съседни контроли, се извършва на два етапа:

1. За контролата се извиква методът Invalidate(), който обявява за невалидна дадената контрола или отделен неин участък и изпраща заявка за пречертаване. Invalidate() реално маркира регионите от контролата, които по някаква причина имат нужда от пречертаване и след това й изпраща съобщение "пречертай" (WM_PAINT), което се изпълнява по-късно.

2. В някакъв момент цикълът за обработка на съобщения на текущата нишка получава съобщението "пречертай" и в резултат изпълнява метода Paint() на съответната контрола. Този метод извършва самото графично обновяване на всички невалидни участъци от контролата или в частност я пречертава цялата.

Друг интересен метод, свързан с пречертаването на контролите, е Update() методът. Той може да се използва след Invalidate() за незабавно пречертаване на дадена контрола чрез насилствено извикване на Paint(), без да се изчаква Paint() да бъде извикан от цикъла за обработка на съобщения за текущата нишка.

Съобщението "пречертай"

Съобщението "пречертай" (WM_PAINT) е специално съобщение. То се обработва последно, едва след като всички останали съобщения от опашката на главната нишка вече са обработени и в нея останат само съобщения "пречертай". Това осигурява намаляване на претрепванията на контролите, когато те се променят много пъти за кратко време.

Например, ако при обработката на дадено събитие на дадена контрола бъде изпратено 5 пъти съобщение "пречертай", контролата ще изпълни само едно пречертаване и то едва след като формата е обработила всички останали съобщения и е станало ясно кои контроли в момента са невалидни и трябва да се пречертаят.

Реалното графично изобразяване на заявените за пречертаване контроли се извършва, когато те обработват съобщението "пречертай", което може да е много след като пречертаването е заявено.

Когато се пречертават няколко контроли последователно, те винаги се пречертават в реда, в който контролите са поставени в контейнер-контролата (т. нар. Z-order). Първи се пречертават най-рано поставените контроли, а последни – най-късно поставените.

Реализация на пречертаването

Всяка Windows Forms контрола може да дефинира програмен код, който реализира изчертаването на нейното съдържание (метод Paint()).

Windows Forms контролите могат да се поставят една върху друга със застъпване. Понеже при пречертаване контролите се изобразяват една след друга по реда на поставянето им, ако има застъпвания, последно поставената контрола закрива (частично или напълно) всички контроли, с които се застъпва.

По-нататък в настоящата тема ще дадем примерен код, който реализира пречертаването на контрола чрез използване на графичните примитиви от GDI+.

Управление на фокуса и навигация

В една форма в даден момент може някоя от контролите да е активна, т.е. да държи фокуса. Контролата, която е на фокус, обикновено показва това по някакъв начин – бутонът променя графичния си вид, текстовото поле показва мигащ курсор и т.н.

При настъпване на събитие от клавиатурата, то се получава първо от контролата, която е на фокус. Например, ако едно текстово поле е на фокус и потребителят натисне клавиш, който съответства на някоя буква, текстовото поле обикновено приема буквата и я изписва на позицията на курсора. Ако текстовото поле не обработи натиснатия клавиш (например, ако това е клавиш за навигация [Tab]), той се обработва от контейнер-контролата.

Windows Forms осигурява навигация между контролите чрез клавишите [Tab] и [Shift+Tab], които преместват фокуса към следващата или предходната контрола. Коя е следващата и коя е предишната контрола се определя от т. нар. "Tab Order", който зависи от реда на поставяне на контролите във формата и от някои свойства на контролите.

Формите също могат да са на фокус (да са активни) или да не са. Фокусът между формите може да се променя от потребителя само при немодални форми. Модалните форми не позволяват друга форма да приема фокуса, докато не бъдат затворени.

Текущата фокусирана контрола и форма могат да се променят, както в резултат от потребителски действия от клавиатурата и мишката, така и програмно - чрез изпращане на подходящи съобщения или извикване на подходящи методи. Има контроли, които не могат да приемат фокуса, и контроли, които могат да го приемат, но се прескачат при натискане на [Tab] и [Shift+Tab].

Основни класове в Windows Forms

Библиотеката Windows Forms дефинира съвкупност от базови класове за контролите, контейнер-контролите, както и множество графични контроли и неграфични компоненти.

Основните базови класове, използвани в Windows Forms, са:

- System.ComponentModel.Component – представлява .NET компонент. Използва се за реализацията на неграфични компоненти. Например компонентата System.Windows.Forms.Timer е наследник на класа Component.

- System.Windows.Forms.Control – представлява графична контрола. Графични контроли са компонентите, които имат графичен образ. Всички Windows Forms контроли са наследници на класа Control, включително и контейнер-контролите.

- System.Windows.Forms.ScrollableControl – представлява контрола, която поддържа скролиране на съдържанието си. Може да съдържа в себе си други контроли.

- System.Windows.Forms.ContainerControl – представлява контрола, която съдържа в себе си други контроли и осигурява управление на фокуса. Не всички контейнер-контроли наследяват този клас. Например панелът (System.Windows.Forms.Panel) може да съдържа в себе си други контроли, но е наследник на класа ScrollableControl, а не на ContainerControl.

Йерархия на класовете

На клас-диаграмата по-долу е показана част от класовата йерархия на библиотеката Windows Forms:

Забелязва се, че не всички класове от Windows Forms са контроли. Някои са обикновени .NET компоненти, например Menu, Timer и ImageList. Изглежда малко странно защо менюто не е контрола, но това е така, защото компонентата Menu реално няма графичен образ и представлява списък от MenuItem елементи. MenuItem класът вече има графичен образ и следователно е контрола.

Типичните контроли (Label, TextBox, Button, ToolBar, StatusBar и др.) са наследници на класа Control. Общото за всички тях е, че имат графичен образ и се управляват чрез съобщения.

Контролите, които могат да се скролират (например панелите) са наследници на ScrollableControl. Контролите, които съдържат други контроли и се грижат за управление на фокуса (например формите и диалозите), наследяват ContainerControl.

Класът Control

Класът System.Windows.Forms.Control заема много централна роля в библиотеката Windows Forms. Той е базов клас, основа за всички графични контроли, и определя единна рамка за контролите – програмен модел, по който да се разработват и изпълняват. В него са дефинирани общите за всички контроли свойства и събития.

Свойства на класа Control

Нека сега разгледаме по-важните свойства на класа Control:

- Anchor, Dock – задават по какъв начин контролата се "закотвя" за контейнера си. Тези свойства са много полезни, ако искаме да управляваме размерите и позицията на контролата при промяна на размерите на контейнера, в който е поставена. Например чрез свойството Anchor можем да закотвим дадена контрола на определено разстояние от долния десен ъгъл на формата, в която стои, и при преоразмеряване това разстояние ще се запазва и контролата ще се движи заедно с движението на долния десен ъгъл на контейнера, в който е поставена.

- Bounds – задава размера (ширина и височина) и позицията на горния ляв ъгъл на контролата в рамките на нейния контейнер. Ако контролата е форма, позицията се задава спрямо горния ляв ъгъл на екрана. Ако контролата е елемент от форма (например бутон), позицията се отчита спрямо горния ляв ъгъл на формата (или контейнер-контролата), в която е оставена. Размерът включва цялото графично пространство на контролата. Например, ако контролата е форма, се включва и нейната рамка.

- BackColor – задава цвета на фона. Цветовете са инстанции на структурата System.Drawing.Color, която дефинира множество стандартни цветове и позволява потребителски дефинирани цветове, състоящи се от 4 на брой 8-битови компонента (яркост, червено, зелено и синьо).

- ContextMenu – задава контекстно меню (popup menu) за контролата. Контекстното меню обикновено се появява при натискане на десния бутон на мишката върху контролата.

- Controls – съдържа колекция от вложените в контролата други контроли (ако има такива). Например формите (инстанции на класа Form) съдържат в колекцията си Controls контролите, които са разположени в тях. По принцип всички Windows Forms контроли имат колекция Controls и могат да съхраняват в нея други контроли, но за някои от тях не е коректно това да се прави. Например не е коректно в бутон да поставяме друг бутон или текстово поле. Ако го направим, се появяват неприятни аномалии.

- CanFocus – връща дали контролата може да получава фокуса. Почти всички видове контроли могат да бъдат фокусирани, стига да не са забранени (Enabled=false).

- Enabled – позволява забраняване на контролата. Когато една контрола бъде забранена (Enabled=false), тя остава видима, но става неактивна. Обикновено забранените контроли се изобразяват с избледнял цвят, за да се различават от останалите. Забранените контроли не могат да получават фокуса. В частност забранен бутон не може да бъде натиснат, в забранено текстово поле не може да се пише и т.н. Ако забраним контейнер-контрола, която съдържа в себе си други контроли, всички тези контроли стават забранени.

- Font – задава шрифта, с който се изписва текстът в контролата (ако контролата по някакъв начин визуализира текст). При текстови полета това е шрифтът на текста в полето. При бутон това е шрифтът на текста в бутона. При етикет това е шрифтът на текста на етикета. Ако се зададе свойството Font за формата, всички контроли, които не дефинират изрично Font, го наследяват от формата. Шрифтът, с който е изобразено заглавието на формите, не може да се променя от Windows Forms. Той се настройва от графичната среда на операционната система (от контролния панел при Windows).

Шрифтовете имат следните характеристики: наименование на шрифт (например Arial) или фамилия шрифтове (например Monospace, SansSerif или Serif), стил (например Bold, Italic, ...), размер (например 12 pt или 10 px) и кодова таблица (Cyrillic, Western, Greek, ...). Кодовата таблица е необходима рядко – само за старите шрифтове, които не поддържат Unicode.

- ForeColor – задава цвета на контролата.

- Location – съдържа позицията на контрола в нейния контейнер (координатите на горния й ляв ъгъл). За форми това е позицията на екрана, а за други контроли това е позицията във формата или контейнер-контролата.

- Parent – задава контейнер-контролата, в която се намира текущата контрола. Може и да няма такава (стойност null). Формите най-често имат стойност null за свойството Parent.

- Size – съдържа размерите на контролата (ширина и височина).

- TabIndex – определя реда при навигация с [Tab] и [Shift+Tab].

- TabStop – задава дали контролата трябва да се фокусира при навигация с [Tab] и [Shift+Tab]. Ако се зададе TabStop=false, фокусът не спира в контролата при преминаване към следващата контрола (контролата се прескача).

- Text – задава текст, свързан с контролата. При етикет това е текстът, изобразен в етикета. При бутон това е текстът, изобразен в бутона. При текстово поле това е текстът, въведен в полето. При форма това е заглавието на формата. Текстът е в Unicode и това позволява да се използват свободно букви и знаци на латиница, кирилица, гръцки, арабски и други азбуки, стига избраният шрифт да съдържа съответните знаци.

- Visible – задава видимост на контролата. Ако за дадена контрола се зададе Visible=false, тя се скрива (изчезва, все едно не съществува). Скрита контрола може да се покаже отново, като й се зададе Visible=true.

Методи на класа Control

Публичните методи на класа Control се наследяват и са достъпни във всички Windows Forms контроли. По-важните от тях са:

- Focus() – фокусира контролата (ако е възможно).

- Hide(), Show() – скрива/показва контролата (ефектът е като да зададем Visible=false / Visible=true).

Събития на класа Control

Знаем колко са важни събитията за Windows Forms контролите. Благодарение на тях програмистът може да пише код, който се задейства при различни промени в състоянието на контролите. Ще разгледаме по-важните събития на класа Control:

- Click – настъпва при щракване с мишката върху контролата. При бутон това събитие се извиква при натискане на бутона. При форма Click се извиква при щракване с левия бутон на мишката върху формата, ако в съответната позиция няма друга контрола. Събитието не подава допълнителна информация в аргументите си.

- Enter, Leave – настъпват съответно при активиране и деактивиране на дадена контрола, т.е. когато контролата получи и загуби фокуса. При форми тези събития не се извикват.

- KeyDown, KeyUp – настъпват при натискане и отпускане на произволен клавиш (включително специалните клавиши като [F1], [Alt], [Caps Lock], [Start] и др.). Събитието подава в аргументите си инстанция на класа KeyEventArgs, която съдържа информация за натиснатия клавиш – име на клавиша (инстанция на изброения тип System.Windows.Forms.Keys) и информация за състоянието на клавишите [Shift], [Alt] и [Ctrl].

- KeyPress – настъпва при натискане на неспециален клавиш или комбинация от клавиши. Това събитие се активира само ако натиснатата клавишна комбинация се интерпретира като символ. Например натискането на клавиша [Alt] не води до получаване на символ и не задейства това събитие, докато натискането на клавиша [V] генерира някакъв символ в зависимост от текущия език. Събитието подава в аргументите си инстанция на KeyPressEventArgs класа, която съдържа символа, генериран в резултат от натискането на клавиша.

- MouseDown, MouseMove, MouseUp, MouseWheel – настъпват при събития от мишката, извършени върху контролата – натискане на бутон, движение на показалеца на мишката или преместване на колелото. Събитията подават в аргументите си инстанция на MouseEventArgs класа, която съдържа информация за състоянието на бутоните и колелото на мишката и за координатите на показалеца (изчислени спрямо горния ляв ъгъл на контролата).

- MouseEnter, MouseLeave, MouseHover – настъпват при навлизане, излизане и преместване на позицията на показалеца на мишката в рамките на контролата.

- Move – настъпва при преместване на контролата. Преместването може да се предизвика от потребителя (например преместване на форма) или програмно (чрез промяна на свойството Location).

- Paint – настъпва при пречертаване на контролата (при обработката на съобщението WM_PAINT). В това събитие контролата трябва да извърши пречертаването на графичния си образ. Събитието получава в аргументите си инстанция на PaintEventArgs, която съдържа Graphics обекта, върху който трябва да се извърши чертането.

- Resize – настъпва при промяна на размера на контролата. Може да се предизвика както от потребителя (при преоразмеряване на форма), така и програмно (при промяна на свойството Size).

- TextChanged – настъпва при промяна на свойството Text на контролата.

- Validating – използва се за валидация на данните, въведени в контролата. Валидацията на данни ще бъде дискутирана по-късно в настоящата тема.

Класът ScrollableControl

Класът ScrollableControl е наследник на класа Control и добавя към него функционалност за скролиране. Ето по-важните му свойства:

- AutoScroll – задава дали при нужда контролата ще получи автоматично скролиращи ленти.

- HScroll, VScroll – задават дали контролата да има хоризонтална и вертикална скролираща лента.

Класът ContainerControl

Класът ContainerControl осигурява функционалност за управление на фокуса. Свойството му ActiveControl съдържа във всеки един момент контролата, която е на фокус.

Форми, прозорци и диалози

Формите и диалозите в Windows Forms са прозорци, които съдържат контроли. Те могат да бъдат различни видове: да имат или нямат рамка, да са модални или не, да са разтегливи или не, да са над всички други прозорци или не и т.н.

Класът System.Windows.Forms.Form

Класът System.Windows.Forms.Form е базов клас за всички форми в Windows Forms GUI приложенията. Той представлява графична форма - прозорец или диалогова кутия, която съдържа в себе си контроли и управлява навигацията между тях.

Повечето прозорци имат рамка и специални бутони за затваряне, преместване и други стандартни операции. Външният вид на прозорците и стандартните контроли по тяхната рамка зависят от настройките на графичната среда на операционната система. Програмистът има само частичен контрол над външния вид на прозорците.

Класът Form е наследник на класовете Control, ScrollableControl и ContainerControl и наследява от тях цялата им функционалност, всичките им свойства, събития и методи.

По-важни свойства на класа Form

Всички прозорци и диалози в Windows Forms наследяват класа Form и придобиват от него следните свойства:

- FormBorderStyle – указва типа на рамката на формата. По-често използваните типове рамка са следните:

o Sizable – стандартна разширяема рамка. Потребителят може да променя размерите на такива рамки.

o FixedDialog – диалогова рамка с фиксирани размери. Такива рамки не могат да се преоразмеряват от потребителите.

o None – липса на рамка. Цялото пространство на формата се използва за нейното съдържание.

o FixedToolWindow – кутия с инструменти с фиксиран размер. Рамката не може да се преоразмерява от потребителите и е малко по-тясна от стандартната. Прозорци с такива рамки не се виждат в лентата на задачите (taskbar) на Windows Explorer и при натискане на [Alt+Tab].

- Controls – съдържа списък с контролите, разположени във формата. От реда на контролите в този списък зависи редът, в който те се чертаят на екрана (Z-order) и редът, в който се преминава от една контрола към друга при навигация (tab order). Редът на преместване на фокуса може да се настройва и допълнително от свойствата TabStop и TabIndex.

- Text – заглавие на прозореца. Използва се Unicode, т.е. можем да използваме, кирилица, латиница, гръцки и други азбуки от Unicode стандарта.

- Size – размери на прозореца (ширина и височина). Включва цялото пространство, заемано от формата (рамката + вътрешността).

- ClientSize – размери на вътрешността на формата (без рамката й).

- AcceptButton – бутон по подразбиране. Този бутон се натиска автоматично, когато потребителят натисне клавиша [Enter], независимо от това в коя контрола от формата е фокусът в този момент. Целта е да се улесни потребителя при попълването на форми с информация.

- ActiveControl – съдържа контролата, която държи фокуса. При промяна на това свойство се променя текущата фокусирана контрола.

- ControlBox – задава дали формата трябва да съдържа стандартните контроли за затваряне, минимизация и т. н.

- Icon – задава икона на прозореца.

- KeyPreview – ако се зададе true, позволява формата да обработва събитията от клавиатурата, преди да ги предаде на фокусираната контрола. Ако стойността е false, всяко събитие от клавиатурата се обработва само от контролата, която е на фокус.

- MinimumSize, MaximumSize – задава ограничения за размера на формата – максимална и минимална ширина и височина. При опит за преоразмеряване не се позволява потребителят да задава размер, който не е в тези граници.

- Modal – връща дали формата е модална. Когато една форма е модална, докато тя е активна, потребителят не може да работи с други форми от същото приложение. Всеки опит за преминаване в друга форма не успява, докато потребителят не затвори модалната форма. Ако дадено приложение покаже едновременно няколко форми, които не са модални, потребителят ще може да преминава свободно между тях, без да ги затваря. Свойството Modal е само за четене. Модалността може да се задава първоначално, но не може да се променя, след като формата е вече показана.

- Opacity – задава прозрачност на формата (число от 0.00 до 1.00). Възможно е да не се поддържа или да работи много бавно при някои по-стари видеоадаптери.

- MdiChildren – в MDI режим извлича / задава подчинените форми на текущата форма. MDI (Multiple-Document Interface) е режим, при който дадена форма на приложението (обикновено главната форма) може да съдържа в себе си други форми, които са разположени в нейното работно пространство (като обикновени контроли).

- MdiParent – в MDI режим извлича / задава формата, която е собственик на текущата форма. Важи само за подчинени (child) форми.

- TopMost – задава дали формата стои над всички други прозорци (always on top). В такъв режим, дори ако формата не е активна, тя остава видима и стои над всички останали форми.

- WindowState – извлича състоянието на формата. Формата във всеки един момент е в някое от състоянията на изброения тип FormWindowState – нормално, минимизирано или максимизирано. По подразбиране формите са в нормално състояние – имат нормалния си размер. В максимизирано състояние формите временно променят размера си и заемат целия екран без лентата за задачи (task bar) на Windows Explorer. В минимизирано състояние формите са скрити и се виждат само в лентата за задачи (task bar).

По-важни методи на класа Form

Прозорците и диалозите в Windows Forms наследяват от класа Form следните базови методи:

- Show() – показва формата и я прави активна (фокусира я). Формата се показва в немодален режим. Извикването на този метод е еквивалентно на присвояването Visible=true. Изпълнението на този метод приключва веднага.

- ShowDialog() – показва формата в модален режим и след като тя бъде затворена, връща като резултат стойност от тип DialogResult. Тази стойност съдържа информация за причината за затваряне на формата. Изпълнението на метода ShowDialog() приключва едва след затваряне на формата, т.е. методът е блокиращ. По-нататък в настоящата тема ще обърнем специално внимание на извикването на модални форми и получаването на стойностите от контролите в тях.

- Close() – затваря формата. Когато една форма бъде затворена, тя изчезва и се освобождават използваните от нея ресурси. След като една форма бъде затворена, тя не може да бъде повече показвана. За временно скриване на форма трябва да се използва методът Hide(), а не Close().

- LayoutMdi(…) – в MDI режим този метод пренарежда дъщерните (child) форми, съдържащи се в текущата форма. Начинът на пренареждане се задава от програмиста. Поддържат се няколко вида пренареждане - каскадно, хоризонтално, вертикално и др.

По-важни събития на класа Form

Всички прозорци и диалози в Windows Forms поддържат съвкупност от стандартни събития, които наследяват от класа Form:

- Activated / Deactivate – извикват се при активиране / деактивиране на формата (когато формата получи / загуби фокуса).

- Closing – извиква се при опит за затваряне на формата (например, когато потребителят натисне стандартния бутон за затваряне). Реализацията може да предизвиква отказване на затварянето. Събитието подава в аргументите си инстанция на класа CancelEventArgs, която има булево свойство Cancel, чрез което може да се откаже затварянето.

- Load – извиква се еднократно преди първото показване на формата. Може се ползва за инициализиране на състоянието на контролите.

Основни контроли в Windows Forms

Да разгледаме най-често използваните контроли в Windows Forms: TextBox, Label и Button.

TextBox

TextBox контролата е поле за въвеждане на текст. Може да бъде едноредово или многоредово. По-важните свойства на TextBox са:

- Multiline – задава дали контролата представлява само един ред или допуска въвеждането на няколко реда текст.

- Text – съдържа въведения в контролата текст. Когато свойството Multiline е true, за достъп до въведения текст може да се използва и свойството Lines.

- Lines – масив от символни низове, съдържащ въведения текст. Всеки елемент от масива съдържа един от редовете на текста.

Label

Контролата Label се използва за изобразяване на текст във формата. Свойството й Text съдържа текста, който се изобразява.

Button

Контролата Button представлява бутон, който може да бъде натискан. По-важни нейни свойства и събития са:

- Click – активира се при натискане на бутона.

- Text – задава текста, изобразяван върху бутона.

Поставяне на контроли във формата

Поставянето на контроли във форма става чрез добавянето им към колекцията от контроли на формата. Това може да се извърши чрез метода Controls.Add(…):

Form form = new Form();

Button button = new Button();

button.Text = "Close";

form.Controls.Add(button);

Редът на контролите (т. нар. Z-order, който споменахме по-рано в тази тема) се определя от реда на поставянето им – последната контрола е най-отгоре. Когато използваме Windows Forms дизайнерът на Visual Studio .NET, той се грижи за правилното поставяне на контролите.

Управление на събитията

Прихващането на събитие става чрез добавянето на обработчик за него. За целта създаваме метод, който ще обработва събитието, и след това се абонираме за него. Ето пример:

Form form = new Form();

Button button = new Button();

button.Click += new EventHandler(this.button_Click);

...

private void button_Click(object sender, EventArgs e)

{

// Handle the "click" event

}

Windows Forms дизайнерът на Visual Studio .NET улеснява прихващането на събития, като генерира автоматично обработчиците при избор на събитие от страницата "Events" на прозореца "Properties".

В Windows Forms има няколко типа събития:

- EventHandler – извършва проста нотификация, без да подава допълнителни данни за възникналото събитие.

- KeyEventHandler – събития от клавиатурата. Подава се информация кой е натиснатият клавиш, както и информация за състоянието на клавишите [Ctrl], [Shift] и [Alt].

- MouseEventHandler – събития от мишката. Подава се информация за позицията на мишката и състоянието на нейните бутони.

- CancelEventHandler – събития, които могат да откажат започнатото действие. Примерно, ако прихващаме събитието Closing на дадена форма, което е от тип CancelEventHandler, и потребителят се опита да затвори формата, можем да откажем затварянето, ако данните не са запазени.

Прост калкулатор – пример

Настоящият пример илюстрира използването на Windows Forms за създаването на просто приложение – калкулатор за събиране на цели числа:

using System;

using System.Drawing;

using System.Windows.Forms;

public class CalculatorForm : Form

{

private TextBox TextBoxNumber1;

private TextBox TextBoxNumber2;

private TextBox TextBoxSum;

private Button ButtonCalc;

private Label LabelPlus;

private Label LabelEquals;

public CalculatorForm()

{

TextBoxNumber1 = new TextBox();

TextBoxNumber1.Bounds = new Rectangle(

new Point(16, 16), new Size(72, 20));

TextBoxNumber1.MaxLength = 10;

LabelPlus = new Label();

LabelPlus.AutoSize = true;

LabelPlus.Location = new Point(94, 19);

LabelPlus.Text = "+";

TextBoxNumber2 = new TextBox();

TextBoxNumber2.Bounds = new Rectangle(

new Point(112, 16), new Size(72, 20));

TextBoxNumber2.MaxLength = 10;

LabelEquals = new Label();

LabelEquals.AutoSize = true;

LabelEquals.Location = new Point(191, 18);

LabelEquals.Text = "=";

TextBoxSum = new TextBox();

TextBoxSum.Bounds = new Rectangle(

new Point(208, 16), new Size(72, 20));

TextBoxSum.ReadOnly = true;

ButtonCalc = new Button();

ButtonCalc.Bounds = new Rectangle(

new Point(16, 48), new Size(264, 23));

ButtonCalc.Text = "Calculate sum";

ButtonCalc.Click += new EventHandler(

this.ButtonCalc_Click);

this.AcceptButton = ButtonCalc;

this.ClientSize = new Size(298, 87);

this.Controls.Add(TextBoxNumber1);

this.Controls.Add(LabelPlus);

this.Controls.Add(TextBoxNumber2);

this.Controls.Add(LabelEquals);

this.Controls.Add(TextBoxSum);

this.Controls.Add(ButtonCalc);

this.FormBorderStyle = FormBorderStyle.FixedDialog;

this.MaximizeBox = false;

this.MinimizeBox = false;

this.Text = "Calculator";

}

private void ButtonCalc_Click(object aSender, EventArgs aArgs)

{

try

{

int value1 = Int32.Parse(TextBoxNumber1.Text);

int value2 = Int32.Parse(TextBoxNumber2.Text);

int sum = value1 + value2;

TextBoxSum.Text = sum.ToString();

}

catch (FormatException)

{

TextBoxSum.Text = "Invalid!";

}

TextBoxNumber1.SelectAll();

TextBoxNumber2.SelectAll();

TextBoxNumber1.Focus();

}

static void Main()

{

CalculatorForm CalcForm = new CalculatorForm();

Application.Run(CalcForm);

}

Как да компилираме и стартираме примера?

За да компилираме примера, можем да ползваме конзолния компилатор на .NET Framework за езика C#:

csc CalculatorForm.cs

Можем да извършим компилацията и от VS.NET, но за целта трябва да създадем нов Windows Application проект и да копираме кода в него.

Ето как изглежда примерното приложение в действие:

Как работи примерът?

В примера сме дефинирали класа CalculatorForm, който наследява класа System.Windows.Forms.Form. Този клас представлява главната форма на нашето приложение.

В класа дефинираме необходимите ни контроли – три TextBox контроли (две за въвеждане на числа и една за извеждане на сумата им), две Label контроли и един бутон, при натискането на който ще се изчислява резултатът от събирането на числата.

В конструктора на формата инициализираме контролите и ги добавяме в нея. За целта им задаваме размери, местоположение и някои други свойства. За текстовите полета, в които потребителят ще въвежда числата, които ще събираме, задаваме максималната им дължина в брой символи. За Label контролите задаваме текста, който ще визуализират. За бутона задаваме заглавие. Накрая задаваме начина, по който ще изглежда нашата форма.

В метода CalcButton_Click(…) обработваме събитието Click на бутона за изчисляване на сумата. В него парсваме съдържанието на двете текстови полета, сумираме числовите стойности, получени от тях, и записваме сумата в третото текстово поле. При грешка задаваме невалиден резултат.

Windows Forms редакторът на VS.NET

Създаването на форми, добавянето на контроли, настройката на размерите и местоположението на контролите и други такива операции, можем да извършваме, пишейки директно кода за нашето приложение, както в предходния пример. Разработката на приложения и създаването на потребителски интерфейс по този начин, обаче, е трудоемък и времеотнемащ процес.

Windows Forms редакторът на VS.NET ни дава възможност да правим всички тези неща визуално, ускорявайки процеса на разработка. Той улеснява значително извършването на следните операции:

- създаване на форми

- добавяне на контроли във формите

- добавяне на неграфични компоненти във формите

- настройка на свойствата на форми, компоненти и контроли

- добавяне на събития за форми, компоненти и контроли

Създаване на форма

Създаването на форма във VS.NET става, като от менюто File изберем Add New Item. В появилия се диалогов прозорец избираме Windows Form, в полето за име въвеждаме името на формата и натискаме бутона Open. Нашата нова форма се отваря в редактора на VS.NET:

Добавяне на контрола

Добавянето на контрола става, като отворим формата, щракнем върху контролата в Toolbox, след това щракнем върху формата там, където искаме да е горният ляв ъгъл на контролата, и изтеглим мишката до там, където искаме да е долният й десен ъгъл. Контролата се добавя във формата с определеното местоположение и размери:

Всички контроли имат подразбиращ се размер. Ако желаем да добавим контрола с подразбиращия се размер, можем просто да я изтеглим от Toolbox и да я пуснем във формата (drag and drop).

Добавяне на неграфични компоненти

За да добавим неграфична компонента, отваряме формата, щракваме върху компонентата в Toolbox и я изтегляме върху формата. Тъй като неграфичните компоненти нямат потребителски интерфейс, те не се показват върху формата, а се изобразяват в специална област под нея:

Настройка на свойства

Настройката на свойства се извършва в прозореца Properties на редактора. Ако прозорецът не е видим, можем да го покажем, като изберем View | Properties Window от менюто, натиснем [F4] или изберем Properties от контекстното меню, появяващо се при щракване с десния бутон на мишката върху контролата. От падащия списък, намиращ се най-отгоре в прозореца, избираме обекта, чиито свойства ще настройваме. След това избираме свойството, което ще променяме, и му задаваме стойност. В зависимост от свойството ще зададем текст, числова стойност или ще изберем стойността от списък. Ето как изглежда прозорецът Properties на VS.NET:

Добавяне на обработчици на събития

Добавянето на обработчици на събития също става от прозореца Properties на VS.NET:

За целта от падащия списък, намиращ се най-отгоре в прозореца, избираме обекта, чиито свойства ще настройваме, и натискаме бутона Events, намиращ се под падащия списък. Появяват се събитията на обекта. От падащия списък срещу събитието, за което искаме да добавим обработчик, избираме метода, който ще обработва събитието. Ако ще дефинираме нов метод за обработка на събитието, изписваме неговото име в полето. Друга възможност е да щракнем 2 пъти с мишката и VS.NET ще избере име по подразбиране (името на контролата + "_" + името на събитието, примерно OkButton_Click). При създаване на обработчик за събитие Windows Forms редакторът добавя или намира метода и отваря редактора за код, позициониран точно върху него.

Създаване на калкулатор с Windows Forms редактора на VS.NET – пример

С настоящия пример ще илюстрираме използването на Windows Forms редактора на VS.NET за създаването на просто приложение – калкулатор, който събира цели числа. Функционалността на калкулатора ще е същата като на калкулатора от предишния пример, но този път ще използваме Windows Forms редактора, който ще генерира по-голямата част от кода на приложението.

Ето стъпките за създаването на нашия калкулатор:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име Calculator и заглавие "Simple Calculator". Променяме и името на файла от Form1.cs на Calculator.cs.

3. Вземаме от Toolbox на VS.NET три TextBox, две Label и една Button контроли и ги поставяме в главната форма. Задаваме подходящи имена на поставените компоненти. Препоръчително е името на една контрола да съдържа нейното предназначение и тип (или префикс, указващ типа). В нашия случай подходящи имена са: TextBoxNumber1, TextBoxNumber2, TextBoxSum, LabelPlus, LabelEquals и ButtonCalcSum.

4. Задаваме празен низ в свойството Text на текстовите полета. За полето TextBoxSum задаваме ReadOnly да е true. На свойството Text на ButtonCalcSum задаваме стойност "Calculate sum". На свойствата Text на LabelPlus и LabelEquals задаваме съответно стойности "+" и "=". Ето как изглежда формата на нашия калкулатор в този момент:

5. Остава да дефинираме събитието за натискане на бутона. С двойно щракване върху бутона VS.NET ни дава възможност да напишем кода за обработка на събитието му Click:

private void ButtonCalcSum_Click(object sender,

System.EventArgs e)

{

try

{

int value1 = Int32.Parse(TextBoxNumber1.Text);

int value2 = Int32.Parse(TextBoxNumber2.Text);

int sum = value1 + value2;

TextBoxSum.Text = sum.ToString();

}

catch (FormatException)

{

TextBoxSum.Text = "Invalid!";

}

TextBoxNumber1.SelectAll();

TextBoxNumber2.SelectAll();

TextBoxNumber1.Focus();

}

При натискане на бутона парсваме съдържанието на двете текстови полета, сумираме числовите стойности, получени от тях, и записваме сумата в третото текстово поле. При грешка задаваме невалиден резултат.

6. Приложението вече е готово и можем да го стартираме и тестваме. Ето как изглежда нашият калкулатор:

Диалогови кутии

При разработката на Windows Forms приложения често пъти се налага да извеждаме диалогови кутии с някакви съобщения или с някакъв въпрос. Нека разгледаме стандартните средства за такива ситуации.

Стандартни диалогови кутии

Класът MessageBox ни позволява да извеждаме стандартни диалогови кутии, съдържащи текст, бутони и икони:

- съобщения към потребителя

- въпросителни диалози

Показването на диалогова кутия се извършва чрез извикване на статичния метод Show(…) на класа MessageBox. Следният код, например, ще покаже диалогова кутия със заглавие "Предупреждение" и текст "Няма връзка с интернет":

MessageBox.Show("Няма връзка с Интернет.", "Предупреждение");

Ето как изглежда диалоговата кутия:

Нека разгледаме още един пример за стандартна диалогова кутия с малко повече функционалност:

bool confirmed =

MessageBox.Show("Наистина ли ще изтриете това?",

"Въпрос", MessageBoxButtons.YesNo,

MessageBoxIcon.Question) == DialogResult.Yes;

Този код ще покаже диалогова кутия със заглавие "Въпрос" и текст "Наистина ли ще изтриете това?". Преди текста ще има икона с въпросителен знак в нея, а под него – бутони Yes и No. Ако потребителят натисне Yes, променливата confirmed ще има стойност true, в противен случай ще има стойност false. Ето как изглежда диалоговата кутия от примера:

Повече информация за класа MessageBox може да се намери в MSDN.

Извикване на диалогови кутии

Освен стандартните диалогови кутии можем да използваме и потребителски дефинирани диалогови кутии. Те представляват обикновени форми и се извикват модално по следния начин:

DialogResult result = dialog.ShowDialog();

Методът ShowDialog() показва формата като модална диалогова кутия. Типът DialogResult съдържа резултата (OK, Yes, No, Cancel и др.) от извикването на диалога. Задаването на DialogResult може да става автоматично, чрез свойството DialogResult на бутоните, или ръчно – преди затварянето на диалога чрез свойството му DialogResult.

Ако извиквате форма модално, след това задължително трябва да й извиквате Dispose() метода, за да освободите ресурсите, които тя е използвала. В противен случай те ще се освободят едва когато се активира Garbage Collector и ще се използват ненужно дълго.

DialogResult и предаване на данни между диалози – пример

С настоящия пример ще илюстрираме използването на диалози в Windows Forms, ще покажем как диалозите могат да се извикват един друг и как могат да си предават данни.

В примера ще създадем един диалог, съдържащ текстово поле за въвеждане на име и два бутона – OK и Cancel. Този диалог ще се показва при натискане на бутон от главната форма. Ако потребителят въведе име и натисне OK, ще се показва диалог, съдържащ въведеното име, а ако потребителят затвори диалога, натискайки Cancel, ще се появи диалог, указващ, че е натиснат Cancel.

Ето и стъпките за изграждане на нашия пример:

1. Стартираме VS.NET и създаваме нов Windows Forms проект. В редактора се появява главната форма на приложението. На нея ще се спрем след малко.

2. Създаваме нова форма (File | Add New Item … | Windows Form). Сменяме името й на DialogForm, а името на нейния файл – на DialogForm.cs. Задаваме на свойствата й MinimizeBox и MaximizeBox стойности false, а на свойството FormBorderStyle стойност FixedDialog. Тази форма ще служи за въвеждане на името на потребителя.

3. Вземаме от Toolbox на VS.NET една Label, една TextBox и две Button контроли и ги подреждаме върху формата. Задаваме им подходящи имена. В нашия случай подходящи са имената: LabelYourName, TextBoxName, ButtonOK и ButtonCancel.

4. Задаваме свойството Text на LabelYourName да е "Enter your name:", на ButtonOk да е "OK", на ButtonCancel да е "Cancel", а на TextBoxName – празен низ.

5. Задаваме на свойството DialogResult на бутона ButtonOk стойност OK. По този начин при натискането му формата ще се затвори и ще бъде върнат резултат DialogResult.OK. Аналогично на свойството DialogResult на бутона ButtonCancel задаваме стойност Cancel. Ето как изглежда нашият диалог:

6. Остава да добавим на тази форма едно свойство UserName, което да извлича съдържанието на текстовото поле за въвеждане на потребителско име:

public string UserName

{

get

{

return TextBoxName.Text;

}

7. Поставяме върху главната форма бутон с име ButtonCallDialog и задаваме на свойството му Text стойност "Call Dialog". Чрез този бутон ще извикваме диалога, който създадохме по-рано.

8. Добавяме обработчик на събитието Click на бутона:

private void ButtonCallDialog_Click(object sender,

System.EventArgs e)

{

DialogForm dialog = new DialogForm();

if (dialog.ShowDialog() == DialogResult.OK)

{

string userName = dialog.UserName;

MessageBox.Show("You entered: " + userName);

}

else

{

MessageBox.Show("You canceled the dialog.");

}

dialog.Dispose();

}

В него първо създаваме инстанция на DialogForm. След това извикваме модално формата DialogForm и проверяваме дали е била затворена с бутона OK чрез върнатия DialogResult. Ако е така, извличаме от DialogForm свойството UserName, с което взимаме въведеното в нея име и го показваме в диалогова кутия. Ако не е бил натиснат бутонът OK, това означава, че е бил натиснат бутонът Cancel. В този случай показваме диалогова кутия, указваща, че е натиснат бутон Cancel.

9. Задаваме на главната форма име MainForm и заглавие "Main Form". Променяме и името на файла от Form1.cs на MainForm.cs.

10. Нашето приложение е готово и можем да го стартираме и тестваме:

Други Windows Forms контроли

Вече разгледахме най-основните контроли в Windows Forms – текстовите полета и бутоните. Нека сега разгледаме и някои други контроли, които също се използват често при изграждането на потребителски интерфейс.

CheckBox

CheckBox е кутия за избор в стил "да/не". Свойството й Checked задава дали е избрана.

RadioButton

RadioButton е контрола за алтернативен избор. Тя се използва в групи. Всички RadioButton контроли в даден контейнер (например форма) образуват една група и в нея само един RadioButton е избран в даден момент.

За да създадем няколко групи в една форма, трябва да поставим всяка група в свой собствен контейнер, като например GroupBox, Panel или TabPage. Свойството Checked задава дали контролата е избрана. При промяна на Checked свойството се активира събитието CheckedChanged.

Panel

Panel представлява контейнер, който съдържа група други контроли. Служи за групиране на контроли. Когато преместим даден панел на друга позиция, всички контроли, които са в него, също се преместват. Ако стойността на свойството Enabled на Panel контролата има стойност false, то всички контроли, съдържащи се в нея, ще бъдат деактивирани.

TabControl и TabPage

Контролите TabControl и TabPage осигуряват ползването на табове със страници. TabControl съдържа множество TabPage контроли, които се добавят в него чрез свойството Controls.

ListBox

ListBox контролата се използва за изобразяване на списък със символни низове, които потребителят може да избира чрез щракване с мишката върху тях. По-важните свойства на тази контрола са:

- Items – колекция, която задава списъка от елементи, съдържащи се в контролата.

- SelectionMode – разрешава/забранява избирането на няколко елемента едновременно.

- SelectedIndex, SelectedItem, SelectedIndices, SelectedItems – връщат избрания елемент (или избраните елементи).

CheckedListBox

CheckedListBox изобразява списък от възможности за избор "да/не". По-важни свойства са:

- Items – задава възможностите, от които потребителят ще избира.

- CheckedItems – връща избраните елементи.

ComboBox

ComboBox представлява кутия за редакция на текст с възможност за drop-down алтернативен избор.

- Text – съдържа въведения текст.

- Items – задава възможните стойности, от които потребителят може да избира.

- DropDownStyle – задава стила на контролата – дали само се избира стойност от списъка или може да се въвежда ръчно и друга стойност.

TreeView

TreeView контролата изобразява дървовидни данни. Основни нейни свойства са:

- Nodes – съдържа дървото (списък от TreeNode елементи).

- SelectedNode – съдържа текущо избрания възел в дървото.

RichTextBox

RichTextBox е кутия за редакция на текст с форматиране (Rich Text Format). Методите LoadFile(…) и SaveFile(…) позволяват зареждане и записване на текста от контролата в Rich Text Format (RTF) файл или в текстов файл. Свойствата SelectionStart и SelectionEnd служат за извличане и задаване на областта от текста, която е маркирана. Чрез свойствата SelectionFont, SelectionColor и SelectionAlignment могат да се задават шрифт, цвят и подравняване на текущия маркиран текст.

LinkLabel

LinkLabel контролата е подобна на Label контролата, но изглежда като препратка (hyperlink). Свойството Text задава текстовото съдържание на контролата. При щракване с мишката върху препратката се активира събитието LinkClicked.

PictureBox

PictureBox се използва за изобразяване на картинки. Картинката, която ще се изобразява, се задава чрез свойството Image. Свойството SizeMode задава дали картинката да се разшири/намали или центрира при изобразяването в контролата.

Картинките, използвани в контролата PictureBox, се запазват като ресурси. Те се записват в XML формат в .resx файла на съответната форма и при компилация се запазват като ресурси в асемблито на приложението.

Работа с някои Windows Forms контроли – пример

В настоящия пример ще демонстрираме използването на някои от Windows Forms контролите, които разгледахме: TabControl, TabPage, Panel, RadioButton, GroupBox, CheckedListBox. За целта ще създадем малко приложение, което събира информация от потребителя и след това я показва в диалогов прозорец.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Main Form". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Вземаме от ToolBox на VS.NET един TabControl, поставяме го в горната част на главната форма и му задаваме име TabControl. Под него поставяме един Panel и му задаваме име PanelButtons. На свойствата Dock на поставените контроли задаваме съответно стойности Fill (за таб контролата) и Bottom (за панела). По този начин, при оразмеряване (Resize) на формата, панелът ще си остава отдолу, като се разширява/намалява само странично, а поставеният TabControl ще заема цялото останало пространство. Ето как изглежда формата в този момент:

4. В TabControl контролата добавяме 3 страници (TabPage контроли)– първата за избиране на списък с продукти, втората за въвеждане на адрес и третата за избор на начин на доставка за поръчката. Подходящи имена за тези контроли са съответно TabPageItems, TabPageAddress и TabPageShipping. Добавянето на TabPage става, като щракнем с десния бутон на мишката върху TabControl контролата и от появилото се меню изберем Add Tab.

5. В страницата за избор на продукти добавяме една CheckedListBox контрола с име CheckedListBoxItems и я закотвяме за четирите страни на TabPage контролата чрез свойството Anchor от прозореца Properties на редактора. По този начин контролата ще се преоразмерява заедно с формата. Задаваме списък от продукти чрез свойството Items и добавяме над контролата един Label с текст "Select items to order:" и име LabelSelectItem.

6. В страницата за въвеждане на адрес добавяме една TextBox контрола с име TextBoxAddress, закотвяме я към четирите страни на страницата чрез свойството Anchor, задаваме на свойството Multiline стойност true, а на свойството Text задаваме празен низ. Добавяме над контролата един Label с текст "Enter your shipping address:" и име LabelEnterAddress.

7. В страницата за избор на начина на доставка добавяме една GroupBox контрола с име GroupBoxShippingMethod и текст Select shipping method. В нея добавяме три RadioButton контроли с имена RadioButtonMail, RadioButtonDHL и RadioButtonFedEx и текст съответно "Mail", "DHL" и "FedEx". Тази комбинация от контроли ни осигурява алтернативен избор на един от възможните доставчици. Най-отдолу в тази страница добавяме и една CheckBox контрола с име CheckBoxTrackShipping и текст "Track shipping". Ето как изглеждат нашите табове в този момент:

8. В панела за бутоните добавяме два бутона с имена ButtonOK и ButtonCancel и текст съответно "OK" и "Cancel". Чрез двукратно щракване върху бутона ButtonCancel добавяме обработчик за събитието му Click, в който добавяме код за затваряне на формата:

private void ButtonCancel_Click(object sender,

System.EventArgs e)

{

Close();

}

9. Остана само да дефинираме обработчик на събитието Click на бутона ButtonOK:

private void ButtonOK_Click(object sender, System.EventArgs e)

{

StringBuilder order = new StringBuilder("Ordered items:\n");

foreach (object item in CheckedListBoxItems.CheckedItems)

{

order.Append(item.ToString());

order.Append("\n");

}

order.Append("Shipping address:\n");

order.Append(TextBoxAddress.Text);

order.Append("\nShipping method: ");

if (RadioButtonMail.Checked)

{

order.Append("Mail");

}

if (RadioButtonDHL.Checked)

{

order.Append("DHL");

}

if (RadioButtonFedEx.Checked)

{

order.Append("FedEx");

}

order.Append("\nTrack shipping: ");

if (CheckBoxTrackShipping.Checked)

{

order.Append("Yes");

}

else

{

order.Append("No");

}

MessageBox.Show(order.ToString(), "Info");

Close();

}

При натискане на бутона извличаме стойностите, въведени във всички контроли, от всички страници, и ги записваме в символен низ. След това ги извеждаме на екрана в стандартна диалогова кутия. За да направим това, първо създаваме един StringBuilder обект, в който ще ги добавяме. След това добавяме стойностите на всички избрани елементи от CheckedListBoxItems контролата, като след всеки от тях добавяме нов ред. Добавяме адреса за доставка, после проверяваме кой RadioButton е избран и добавяме съответния метод за доставка към StringBuilder обекта. Накрая проверяваме състоянието на CheckBox контролата от страницата за начин на доставка и извеждаме извлечената от контролите информация в стандартна диалогова кутия.

10. Нашето приложение е готово и можем да го стартираме и тестваме:

Менюта

Менютата са важно средство, чрез което потребителят по удобен начин указва започването на дадена операция. Те са на практика стандарт при приложенията с графичен потребителски интерфейс. В Windows Forms за работа с менюта се използват класовете MainMenu, ContextMenu и MenuItem.

MainMenu

MainMenu компонентата представлява стандартно падащо меню. Тя съдържа в себе си списък от MenuItem елементи, които представят отделните възможности за избор (команди) от менюто.

ContextMenu

ContextMenu компонентата представлява контекстно меню (popup меню), което се появява, когато потребителят щракне с десния бутон на мишката върху контрола или някъде във формата. Тя съдържа списък от MenuItem елементи, представляващи отделните команди от менюто.

MenuItem

MenuItem елементите представляват отделните възможности за избор, показвани в MainMenu или ContextMenu. Всеки MenuItem елемент може да бъде команда в приложението или родителско меню за други елементи, (менютата могат да се влагат). По-важни събития и свойства на класа MenuItem са:

- Text – задава заглавието на елемента, например "&New", "&Open…" или "-". Символът "&" задава горещ клавиш за бързо избиране на съответния елемент. Поставя се преди дадена буква от текста на елемента. Елемент от менюто с текст "-" задава разделител.

- ShortCut – кратък клавиш, асоцииран с този елемент. Например може да се укаже, че [Ctrl+S] съответства на елемента от менюто File | Open. В такъв случай указаната клавишна комбинация, независимо кога е натисната, активира този елемент от менюто, стига това да се е случило при активна форма.

- Click – събитие, което се активира при избиране на елемента от менюто.

Ленти с инструменти

Лентите с инструменти са често използвани при приложенията с графичен интерфейс. Нека разгледаме стандартните средства на Windows Forms за работата с тях.

ToolBar

ToolBar контролата представлява лента с инструменти (с бутони). По-важни нейни свойства и събития са:

- Buttons – съдържа списък от бутоните (ToolBarButton елементите), асоциирани с контролата.

- ImageList – задава картинките за бутоните от лентата.

- ButtonClick – събитие, активиращо се при натискане на бутон от лентата. Като параметър то приема ToolBarButtonClickEventArgs с информация кой бутон е бил натиснат.

Не е ясно по каква причина, но проектантите на библиотеката Windows Forms са направили работата с ленти с инструменти доста неудобна. Вместо всеки бутон от лентата да си има собствено събитие Click, има едно общо събитие за цялата лента с инструменти, което се активира при натискане на някой от бутоните. Другият проблем е, че вместо всеки бутон да си има свойство Picture, картинките трябва да се слагат в ImageList компонента и да се ползват по индекс.

ToolBarButton

ToolBarButton компонентата представлява бутон от лентата с инструменти. За всеки бутон от лентата може да се задава картинка, която да се изобразява върху него, текстът за бутона, както и някои други свойства като ToolTipText, който да се показва при задържане на показалеца на мишката върху бутона.

Задаването на изображение на ToolBarButton става, като асоциираме ImageList с лентата с инструменти, в която се намира бутонът, и след това зададем на свойството ImageIndex на бутона стойност с индекса на изображението.

ImageList

ImageList компонентата съдържа списък с картинки. Тя често се използва от други компоненти като ListView, TreeView или ToolBar.

Статус ленти

Статус лентите са още една от типичните контроли в приложенията с графичен интерфейс. Те се използват за визуализация на информация, свързана със състоянието на приложението. Например в текстовите редактори много често в статус лентата се показва номерът на текущия ред и на колона.

StatusBar

StatusBar контролата представлява лента за състоянието. Тя обикновено се състои от StatusBarPanel обекти, показващи текст или икони. Тя може да съдържа и потребителски дефинирани панели, показващи информация за състоянието на приложението. По-важни свойства на контролата са:

- Panels – съдържа секциите, на които е разделена лентата. На фигурата по-горе статус лентата е разделена на 2 секции. Статус лентата може и да няма отделни секции, а да е едно цяло.

- ShowPanels – включва/изключва показването на панелите. Ако секциите са изключени, статус лентата е едно цяло.

StatusBarPanel

StatusBarPanel компонентата представлява секция в лентата за състоянието. Тя може да съдържа текст и/или икона. Чрез свойството Text се задава текстът, който се показва в панела, а чрез свойството Icon се задава икона.

Диалог за избор на файл

При графичните приложения често се налага да се избира файл от локалната файлова система, например, когато трябва да бъде зареден или записан документ във файл. За тази цел Windows Forms предоставя стандартни диалози, които могат да се настройват по гъвкав начин.

OpenFileDialog

OpenFileDialog представлява диалог за избор на файл (при отваряне). Този клас ни позволява да проверим дали файл съществува и да го отворим. По-важни свойства на диалога са:

- Title – задава заглавие на диалога.

- InitialDirectory – задава началната директория, от която започва изборът на файл. Ако не бъде зададена изрично, се използва последната директория, от която потребителят е избирал файл по време на работа с текущото приложение.

- Filter – задава възможните файлови разширения, измежду които потребителят може да избира (например *.txt, *.doc, ...).

- FilterIndex – задава активния филтър.

- MultiSelect – указва дали в диалога могат да бъдат избирани много файлове едновременно или само един.

- FileName, FileNames – съдържа избраните файлове.

SaveFileDialog

SaveFileDialog представлява диалог за избор на файл (при записване). Този клас ни позволява да презапишем съществуващ или да създадем нов файл. Работата с него е аналогична на работата с OpenFileDialog.

Работа с файлов диалог – пример

Настоящият пример илюстрира работата с файловия диалог на Windows Forms (компонентата OpenFileDialog). За целта ще създадем приложение, което позволява на потребителя да избере текстов файл с помощта на OpenFileDialog, чете съдържанието му и го показва в текстова контрола.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "FileOpenDialog - Demo". Променяме името на файла от Form1.cs на MainForm.cs.

3. Вземаме от ToolBox на VS.NET един TextBox, поставяме го в горната част на главната форма и му задаваме име textBox. Задаваме на свойството му Multiline стойност true и на свойството му ScrollBars стойност Vertical. Така си осигуряваме многоредово текстово поле с възможност за скролиране. Под него поставяме един Panel и му задаваме име PanelBottom. На свойствата Dock на поставените контроли задаваме съответно стойности Fill и Bottom. По този начин, при оразмеряване (Resize) на формата, панелът ще си остава отдолу, като се разширява/намалява само странично, а поставеният TextBox ще заема цялото останало пространство. Ето как изглежда формата в този момент:

4. Поставяме във формата един OpenFileDialog с име openFileDialog. Задаваме на свойството Filter стойност "Text files (*.txt)|*.txt|Log files (*.log)|*.log". Този филтър указва търсене само на текстови (.txt) и log (.log) файлове. На свойството Title задаваме стойност "Choose text file".

5. В панела добавяме един бутон с име ButtonLoadFile и текст "Load file". Чрез двукратно щракване върху бутона добавяме обработчик за събитието му Click:

private void ButtonLoadFile_Click(object sender, System.EventArgs e)

{

if (openFileDialog.ShowDialog() == DialogResult.OK)

{

string fileName = openFileDialog.FileName;

using (StreamReader reader = File.OpenText(fileName))

{

string fileContents = reader.ReadToEnd();

textBox.Text = fileContents;

}

При натискане на бутона показваме диалог за избор на файл и ако потребителят избере файл и натисне бутона [OK], отваряме файла, четем съдържанието му и го показваме в текстовото поле.

6. Нашето приложение е готово и можем да го стартираме и тестваме:

MDI приложения

MDI (Multiple Document Interface) приложенията поддържат работа с няколко документа едновременно, като всеки документ се показва в свой собствен прозорец, разположен във вътрешността на главния прозорец.

MDI контейнери (MDI parents)

MDI контейнерите са форми, които съдържат други форми. За да укажем, че една форма е MDI контейнер, задаваме на нейното свойство IsMdiContainer стойност true. Тези форми обикновено имат меню Window за смяна на активната форма (на свойството му MdiList е зададена стойност true).

MDI форми (MDI children)

MDI формите се съдържат в контейнер-формата. За да укажем, че една форма е MDI форма, задаваме на свойство MdiParent=<контейнер>, където контейнер е MDI контейнер.

Създаване на многодокументов текстов редактор – пример

С настоящия пример ще демонстрираме изграждане на многодокументов текстов редактор със средствата на Windows Forms и Visual Studio .NET. Редакторът трябва да може да създава, редактира, зарежда и записва текстови документи (файлове) и да позволява работа едновременно с много документи в отделни MDI прозорци.

Чрез примерния текстов редактор ще демонстрираме употребата на някои от Windows Forms контролите, които разгледахме: менюта (MainMenu, MenuItem), ленти с инструменти (ToolBar, ImageList, ToolBarButton) и статус ленти (StatusBar, StatusBarPanel). Ще покажем как се създават приложения, работещи в MDI режим. Ще демонстрираме работата с диалога за избор на файл.

Ето стъпките за изграждането на нашия текстов редактор:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Взимаме от ToolBox на VS.NET едно MainMenu, един ToolBar, един ImageList, един StatusBar и един OpenFileDialog и ги поставяме в главната форма. Задаваме подходящи имена на поставените компоненти. Препоръчително е името на една контрола да съдържа нейното предназначение и тип (или префикс, указващ типа). В нашия случай подходящи имена са: MenuMainForm, ToolBarMainForm, ImageListToolBar, StatusBarMainForm и OpenFileDialog.

3. Задаваме за филтър на OpenFileDialog контролата стойността "Text files (*.txt)|*.txt". Този филтър указва търсене само на текстови файлове (.txt).

4. Дефинираме File и Window менюта в главното меню (засега ще ги оставим празни, без елементи в тях).

5. Задаваме на главната форма име MainForm и заглавие "Text Editor Demo". Променяме и името на файла от Form1.cs на MainForm.cs. На картинката по-долу е показано как изглежда разработваното приложение в този момент.

6. Преди да дефинираме бутоните в лентата с инструменти, трябва да заредим подходящи иконки за тях в ImageList контролата. Трябват ни иконка за нов файл, за отваряне на файл и за запис на файл. Можем да използваме стандартните иконки, идващи с VS.NET. Те се намират в директория: C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Graphics\bitmaps\OffCtlBr\Small\Color (при стандартна инсталация на Visual Studio .NET).

7. От редактора за свойствата на компонентите избираме свойството Images на ImageList контролата. Появява се Image Collection Editor, от който можем да добавим иконки в списъка. Добавяме подходящи иконки за нов файл, за отваряне на файл и за запис на файл:

8. За да дефинираме бутоните в лентата с инструменти, първо свързваме ImageList свойството на ToolBar контролата с ImageList компонентата, която заредихме с иконки в предната стъпка. След това използваме свойството Buttons на поставената във формата ToolBar контрола, за да дефинираме бутоните. За редакция на това свойство се използва ToolBarButton Collection Editor, който се появява при опит за редактиране на свойството Buttons:

Добавяме три бутона (за нов файл, за отваряне на файл и за запис на файл) и задаваме за всеки от тях подходящо име и ImageIndex, който го свързва с неговата иконка от ImageList контролата. В този момент в лентата с инструменти се появяват трите бутона с иконки върху тях:

9. Статус лентата ще разделим на две части. В лявата част ще показваме информация за извършените от приложението действия, а в дясната – номера на реда в текущия файл. За целта задаваме на статус лентата ShowPanels=true и добавяме в нея два панела (чрез свойството Panels). Задаваме им имената StatusBarPanelInfo и StatusBarPanelLine и им настройваме размерите:

Статус лентата добива следния вид:

10. За да направим главната форма MDI форма, й задаваме IsMdiContainer=true.

11. Създаваме елементите на главното меню File: New, Open, Save и Exit. За да създадем разделител преди елемента Exit, задаваме на съответната MenuItem контрола Text="-". За Window менюто задаваме MdiList=true, за да показва списък от MDI прозорците в главната форма. За елементите на менюто избираме подходящи имена (например MenuItemFileNew, MenuItemFileOpen, ...). Задаваме и подходящи бързи клавиши (shortcuts) за често използваните команди чрез свойството Shortcut на MenuItem контролата – [Ctrl+N] за File | New, [Ctrl+O] за File | Open, [Ctrl+S] за File | Save и [Alt-F4] за File | Exit. Ето как изглежда главното меню в този момент:

Цялата форма на приложението добива следния вид:

12. Вече имаме главната форма. Остава да добавим формата за редактиране на файловете и да реализираме логиката на приложението. Започваме от дефиниране на събитията за елементите от менюто. С двойно щракване върху елемент от менюто VS.NET ни дава възможност да напишем кода за обработка на събитието му Click:

private void MenuItemFileNew_Click(object sender,

System.EventArgs e)

{

CreateNewFile();

}

private void MenuItemFileOpen_Click(object sender,

System.EventArgs e)

{

OpenExistingFile();

}

private void MenuItemFileSave_Click(object sender,

System.EventArgs e)

{

SaveCurrentFile();

}

private void MenuItemFileExit_Click(object sender,

System.EventArgs e)

{

Close();

}

Методите CreateNewFile(), OpenExistingFile() и SaveCurrentFile() ще разгледаме след малко.

13. Дефинираме и обработчик на събитието натискане на бутон от лентата с инструменти:

private void ToolBarMainForm_ButtonClick(object sender,

System.Windows.Forms.ToolBarButtonClickEventArgs e)

{

if (e.Button == ToolBarButtonNew)

{

CreateNewFile();

}

else if (e.Button == ToolBarButtonOpen)

{

OpenExistingFile();

}

else if (e.Button == ToolBarButtonSave)

{

SaveCurrentFile();

}

Понеже контролата ToolBar не предоставя отделни събития за всеки от бутоните си, трябва да се прихване събитието й ButtonClick и да се проверява за кой от бутоните се отнася то (чрез свойството Button на ToolBarButtonClickEventArgs параметъра).

14. Остава да дефинираме формата за редакция на документ и да реализираме логиката за създаване, редактиране, зареждане и записване на документи. Създаваме нова форма (File | Add New Item … | Windows Form). Сменяме й името на EditorForm, а името на нейния файл – на EditorForm.cs. Тази форма ще служи за редакция на документите. Тя ще се използва като подчинена MDI форма.

15. Добавяме RichTextBox контрола в новата форма. Тя ще служи за редакция на текста на документите. Използваме RichTextBox вместо TextBox, защото RichTextBox позволява работа с по-големи документи и осигурява по-голяма гъвкавост. Задаваме Dock=Fill за RichTextBox контролата и й сменяме името на EditorRichTextBox. Ето как изглежда формата след всички тези действия:

16. Дефинираме в новата форма поле mFileName, което ще съхранява името на текущия отворен файл или null, ако текущият файл няма име (например ако е нов файл):

private string mFileName = null;

17. Поставяме в новата форма един SaveFileDialog. Ще го ползваме при запис на файла, който е зареден в RichTextBox контролата. Задаваме му филтър "Text files (*.txt)|*.txt".

18. Дефинираме няколко метода, които реализират логиката по отваряне на нов документ, зареждане на файл и записване на файл, както и помощен метод за обновяване на статус лентата:

public void CreateNewFile()

{

SetStatusBarInfo("Created new file.");

mFileName = null;

this.Text = "Untitled";

}

public void LoadFile(string aFileName)

{

mFileName = aFileName;

this.Text = Path.GetFileName(aFileName);

using (StreamReader reader = File.OpenText(aFileName))

{

string fileContents = reader.ReadToEnd();

RichTextBoxEditor.Text = fileContents;

}

public void Save()

{

if (mFileName == null)

{

if (SaveFileDialog.ShowDialog() != DialogResult.OK)

{

return;

}

mFileName = SaveFileDialog.FileName;

this.Text = Path.GetFileName(mFileName);

}

using (StreamWriter writer = new StreamWriter(mFileName))

{

writer.Write(RichTextBoxEditor.Text);

}

SetStatusBarInfo("Saved file: " + mFileName);

}

public void SetStatusBarInfo(string aText)

{

MainForm mainForm = (MainForm) this.MdiParent;

mainForm.SetInfoStatusBar(aText);

}

Създаването на нов документ задава заглавие "Untitled" на формата и установява в null името на файла, свързан с нея. Зареждането на файл става с текстов поток. При зареждане формата запомня пълното име на файла, а за заглавие на формата се задава името на файла без пътя. При запис, ако документът не е свързан с файл, се използва файловият диалог за избор на име на файл, в който да се запише. Ако документът е свързан с файл, той просто се записва. Записът става с текстов поток.

19. Дефинираме няколко обработчика на събития и няколко помощни метода с цел визуализация на номера на реда в текущия файл:

private void EditorForm_Activated(object sender,

System.EventArgs e)

{

ShowLineNumber();

}

private void RichTextBoxEditor_SelectionChanged(object sender,

System.EventArgs e)

{

ShowLineNumber();

}

public void SetStatusBarLine(string aText)

{

MainForm mainForm = (MainForm) this.MdiParent;

mainForm.SetLineStatusBar(aText);

}

public void ShowLineNumber()

{

int currentPos = EditorRichTextBox.SelectionStart;

int line = RichTextBoxEditor.GetLineFromCharIndex(currentPos);

SetStatusBarLine("Line: " + line);

}

При активиране на формата и при промяна на позицията на курсора приложението изчислява номера на текущия ред в текущия документ и го показва в десния панел на лентата за състоянието. Достъпът до лентата на състоянието става през родителската MDI форма (това е главната форма на приложението).

20. Дефинираме и обработчик на събитието "затваряне на формата", в който извеждаме информация в статус лентата какво се е случило:

private void EditorForm_Closed(object sender,

System.EventArgs e)

{

if (mFileName != null)

{

SetStatusBarInfo("Closed file: " + mFileName);

}

else

{

SetStatusBarInfo("Closed file.");

}

SetStatusBarLine("");

}

С това формата за редактиране на файлове е готова. Остава само да довършим главната форма и приложението ще е готово.

21. В главната форма пропуснахме да дефинираме методите за отваряне на нов файл, за зареждане на съществуващ файл и за затваряне на файл. Ето как можем да ги реализираме:

private void CreateNewFile()

{

EditorForm editorForm = new EditorForm();

editorForm.MdiParent = this;

editorForm.CreateNewFile();

editorForm.Show();

}

private void OpenExistingFile()

{

if (OpenFileDialog.ShowDialog() != DialogResult.OK)

{

return;

}

string fileName = OpenFileDialog.FileName;

EditorForm editorForm = new EditorForm();

try

{

editorForm.LoadFile(fileName);

editorForm.MdiParent = this;

editorForm.Show();

SetInfoStatusBar("Loaded file: " + fileName);

}

catch (IOException)

{

editorForm.Dispose();

MessageBox.Show("Can not load file: " + fileName, "Error");

}

private void SaveCurrentFile()

{

EditorForm activeEditorForm =

(EditorForm) this.ActiveMdiChild;

if (activeEditorForm != null)

{

activeEditorForm.Save();

}

При създаване и зареждане на файл се създава инстанция на формата за редакция на документи EditorForm и в нея съответно се създава нов документ или се зарежда избрания чрез OpenFileDialog файл, след което тази форма се показва като MDI подчинена в главната.

При записване на текущия документ първо се извлича текущата активна форма (ако има такава) и след това й се извиква методът Save() за записване на отворения в нея документ.

22. Остана само да дефинираме още няколко обработчика на събития за главната форма и няколко помощни метода, които използваме:

private void MainForm_Load(object sender, System.EventArgs e)

{

SetInfoStatusBar("Application started.");

}

public void SetInfoStatusBar(string aText)

{

StatusBarPanelInfo.Text = aText;

}

public void SetLineStatusBar(string aText)

{

StatusBarPanelLine.Text = aText;

}

static void Main()

{

Application.Run(new MainForm());

}

23. Приложението вече е готово и можем да го стартираме и тестваме. Ето как изглежда нашият текстов редактор в действие:

Валидация на данни

Валидацията на данни е необходима, когато в дадена контрола трябва да се допуска въвеждане само на коректни данни, например цяло число, валидна дата и др. В Windows Forms има стандартни средства за валидация:

- Validating – събитие за валидация на данните в класа Control. На събитието се подава параметър от тип CancelEventArgs. Ако на свойството Cancel на този обект се зададе стойност true, то на потребителя не се разрешава да напусне контролата.

- ErrorProvider – отбелязва графично контроли с невалидни данни. До контролата с невалидни данни се появява икона, а когато показалецът на мишката застане над иконата, се появява текст с описание на грешката.

Нека разгледаме следващия фрагмент код, илюстриращ валидацията на данни:

private TextBox TextBox1;

private ErrorProvider errorProvider;

...

private void TextBox1_Validating(object sender,

System.ComponentModel.CancelEventArgs e)

{

try

{

Int32.Parse(TextBox1.Text);

errorProvider.SetError(TextBox1, "");

}

catch (FormatException)

{

errorProvider.SetError(

TextBox1, "Integer number expected!");

e.Cancel = true;

}

Имаме една TextBox контрола, чиито данни ще валидираме, и един ErrorProvider обект, който ще използваме, за да отбелязваме, че контролата съдържа невалидни данни.

В обработчика на събитието Validating на контролата се опитваме да конвертираме текста, съдържащ се в нея, в цяло число. Ако конвертирането пропадне, това означава, че потребителят не е въвел коректни данни. В този случай подаваме на метода SetError(…), на ErrorProvider обекта, нашата контрола и символен низ с описание на грешката. Това описание ще се появи при задържане на мишката над иконата за грешка. Освен това задаваме на свойството Cancel на подадения CancelEventArgs обект стойност true. Това няма да позволи на потребителя да напусне контролата. Ако конвертирането успее, то потребителят е въвел коректни данни. В този случай отново извикваме метода SetError(…), но този път му подаваме като втори параметър празен низ, което предизвиква скриване на иконата, ако тя е била показана.

Валидация на данни – пример

Настоящият пример е малко по-сложен и илюстрира по-пълно средствата за валидация на данни в Windows Forms – събитието Validating и контролата ErrorProvider. Ще създадем просто приложение, състоящо се от две форми – главна форма и форма за въвеждане на ЕГН и година на раждане. Главната форма ще извиква формата за въвеждане на ЕГН и година на раждане и при успешно връщане от нея ще визуализира въведените данни. Във формата за въвеждане на ЕГН и година на раждане ще сигнализираме на потребителя, когато той въведе некоректни данни.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Main Form". Променяме и името на файла от Form1.cs на MainForm.cs. Създаваме и формата за въвеждане на ЕГН и година на раждане (File | Add New Item … | Windows Form). Сменяме името й на ValidationDemoForm, а това на файла й на ValidationDemoForm.cs. Задаваме на свойствата MinimizeBox и MaximizeBox стойности false, а на свойството FormBorderStyle стойност FixedDialog.

3. В новосъздадената форма поставяме две текстови полета с имена TextBoxEGN и TextBoxYear за въвеждане на EГH и година на раждане. Над всяко от тях поставяме по един Label с текст, указващ предназначението на контролата. Поставяме и два бутона с имена ButtonOK и ButtonCancel за потвърждаване и отказване на формата. На свойството DialogResult на ButtonCancel задаваме стойност Cancel.

4. Поставяме във формата един компонент ErrorProvider с име errorProvider, който ще използваме за отбелязване на контролите с невалидни данни. Ето как изглежда на формата в този момент:

5. Добавяме обработчик на събитието Validating на TextBoxEGN контролата:

private void TextBoxEGN_Validating(object sender,

System.ComponentModel.CancelEventArgs e)

{

ValidateEGN();

}

private bool ValidateEGN()

{

if (IsEgnValid(TextBoxEGN.Text))

{

errorProvider.SetError(TextBoxEGN, "");

return true;

}

else

{

errorProvider.SetError(TextBoxEGN, "Невалидно ЕГН!");

return false;

}

private bool IsEgnValid(string aText)

{

if (aText.Length != 10)

{

return false;

}

for (int i=0; i<aText.Length; i++)

{

if (! Char.IsDigit(aText[i]))

{

return false;

}

return true;

}

В обработчика на събитието извикваме функцията ValidateEGN(). В нея, чрез функцията IsEgnValid(…), проверяваме дали въведеното ЕГН е валидно. Ако е валидно, посредством ErrorProvider обекта, изтриваме маркера за грешка до полето за въвеждане на ЕГН и връщаме стойност true, в противен случай задаваме маркер за грешка на полето и връщаме стойност false. Във функцията IsEgnValid(…) проверяваме дали в полето за ЕГН са въведени десет символа и дали всеки от тях е цифра. Ако е така връщаме стойност true, в противен случай връщаме стойност false.

6. Добавяме обработчик на събитието Validating на TextBoxYear контролата:

private void TextBoxYear_Validating(object sender,

System.ComponentModel.CancelEventArgs e)

{

ValidateYear();

}

private bool ValidateYear()

{

if (IsYearValid(TextBoxYear.Text))

{

errorProvider.SetError(TextBoxYear, "");

return true;

}

else

{

errorProvider.SetError(TextBoxYear, "Невалидна година!");

return false;

}

private bool IsYearValid(string aText)

{

string year = TextBoxYear.Text;

if (year.Length != 4)

{

return false;

}

for (int i=0; i<aText.Length; i++)

{

if (! Char.IsDigit(aText[i]))

{

return false;

}

return true;

}

В обработчика на събитието извикваме функцията ValidateYear(). В нея, чрез функцията IsYearValid(…), проверяваме дали въведената година е валидна. Ако е валидна, посредством errorProvider обекта, изтриваме маркера за грешка до полето за въвеждане на година и връщаме стойност true, в противен случай задаваме маркер за грешка на полето и връщаме стойност false. Във функцията IsYearValid(…) проверяваме дали в полето за година са въведени четири символа и дали всеки от тях е цифра. Ако е така, връщаме стойност true, в противен случай връщаме стойност false.

7. Добавяме обработчик на събитието Click на бутона ButtonOK:

private void ButtonOK_Click(object sender, System.EventArgs e)

{

if (ValidateForm())

{

DialogResult = DialogResult.OK;

}

else

{

MessageBox.Show(

"Моля въведете валидни стойности във всички полета!",

"Грешка", MessageBoxButtons.OK, MessageBoxIcon.Error);

}

private bool ValidateForm()

{

if (! ValidateYear())

{

return false;

}

if (! ValidateEGN())

{

return false;

}

string egn = TextBoxEGN.Text;

string year = TextBoxYear.Text;

if (egn.Substring(0,2) == year.Substring(2,2))

{

errorProvider.SetError(ButtonOK, "");

return true;

}

else

{

errorProvider.SetError(ButtonOK,

"Годината на раждане на съответства на ЕГН-то!");

return false;

}

При натискане на бутона проверяваме чрез функцията ValidateForm() дали данните, въведени във формата са валидни. Ако са валидни, задаваме на свойството DialogResult на формата стойност DialogResult.OK, с което връщаме управлението на извикващата форма. Ако данните са невалидни, показваме диалогова кутия с подходящо съобщение.

В метода ValidateForm() проверяваме дали въведените година и ЕГН са валидни чрез функциите ValidateYear() и ValidateEGN(). Ако проверката на някое от тези условия пропадне, връщаме стойност false. След това проверяваме дали първите две цифри на ЕГН-то съвпадат с последните две цифри на годината на раждане. Ако съвпадат, посредством ErrorProvider обекта, изтриваме маркера за грешка до бутона и връщаме стойност true. Ако цифрите се различават, задаваме маркер за грешка на бутона и връщаме стойност false.

8. Добавяме свойства, чрез които да извличаме въведените във формата ЕГН и година на раждане:

public string EGN

{

get

{

return TextBoxEGN.Text;

}

public string Year

{

get

{

return TextBoxYear.Text;

}

9. Добавяме в главната форма бутон с име ButtonShow и текст Show Form. В обработчика на събитието Click на този бутон ще извикваме формата за въвеждане на ЕГН и година на раждане в модален режим и при успешно връщане от нея ще визуализираме въведените данни:

private void ButtonShow_Click(object sender, System.EventArgs e)

{

ValidationDemoForm validationDemoForm = new

ValidationDemoForm();

if (validationDemoForm.ShowDialog() == DialogResult.OK)

{

string s = String.Format("ЕГН: {0}\nГодина: {1}",

validationDemoForm.EGN, validationDemoForm.Year);

MessageBox.Show(s, "Резултат");

}

validationDemoForm.Dispose();

}

10. Приложението вече е готово и можем да го стартираме и тестваме:

Свързване на данни

Свързването на данни (data binding) осигурява автоматично прехвърляне на данни между контроли и източници на данни. Можем например да свържем масив, съдържащ имена на градове, с ComboBox контрола и имената от масива ще се показват в нея.

При добавянето на свързване указваме свойството на контролата, което ще свързваме с данните, източника на данните и път до списък или свойство на източника, към което ще се свържем. Този път може да е име на свойство, йерархия от имена, разделени с точки, или празен низ. Ако пътят е празен низ, ще се извика методът ToString() на обекта, използван като източник на данни.

Свързването на данни е еднопосочно – от контролата към източника на данни!

Промяна на дадено свързано свойство от дадена контрола променя данните в източника, към който то е свързано. Обратното не е вярно. При промяна на източника на данни свързаните към него контроли не си променят свойствата.

Ако сме променили данните в източника на данни и искаме да отразим промените в свързаните с него контроли, трябва първо да премахнем (изтрием) свързването и след това да го добавим отново.

Източници на данни

Като източник на данни можем да използваме всеки клас или компонент, който имплементира интерфейса IList. Такива са масивите и колекциите. За източници на данни можем да използваме и класове или компоненти, които имплементират интерфейса IBindingList. Този интерфейс поддържа нотификация за промяна на данните. IBindingList интерфейсът се имплементира от класа DataView (вж. темата за ADO.NET).

Контроли, поддържащи свързване на данни

Всички Windows Forms контроли поддържат свързване на данни (data binding). Можем да свържем което и да е свойство на контрола към източник на данни.

Видове свързване

В Windows Forms имаме два типа свързване на данни:

- Просто свързване (simple binding) – свързване на контрола с единичен обект или единичен (текущ) елемент от списък. Такова свързване използваме обикновено с контроли като TextBox и CheckBox, които показват единична стойност.

- Сложно свързване (complex binding) – свързване на списъчна контрола със списък. Такова свързване използваме с контроли като ListBox, ComboBox и DataGrid. При него се поддържа текущо избран (активен) елемент от списъка.

Просто свързване

Чрез следващите фрагменти код ще илюстрираме как се осъществява просто свързване на данни в зависимост от източника на данни.

Свързване на контрола към обект

Нека имаме клас Customer, който има свойство Name и TextBox контрола с име TextBoxName. Свързването на свойството Text на TextBox контролата към свойството Name на обект от тип Customer се извършва по следния начин:

class Customer

{

private string mName;

public string Name

{

get { return mName; }

set { mName = value; }

}

Customer cust = new Customer();

cust.Name = "Бай Иван";

TextBoxName.DataBindings.Add(new Binding("Text", cust, "Name"));

Използвахме колекцията DataBindings на класа Control. В нея можем да добавяме Binding обекти, които указват кое свойство на текущата контрола с кое свойство на дадена друга контрола да бъде свързано. В нашия случай при промяна на TextBoxName.Text ще се променя и свойството Name на свързания обект cust.

Свързване на контрола към списък

Нека имаме масив towns, съдържащ имена на градове, и TextBox контрола с име TextBoxTowns. Свързването на свойството Text на TextBox контролата към масива с имена на градове се извършва по следния начин:

string[] towns = {"София", "Пловдив", "Варна"};

TextBoxTowns.DataBindings.Add(new Binding("Text", towns, ""));

Оставили сме пътя до свойството на източника, към което ще се свържем, да е празен низ, защото в случая искаме да свържем свойството Text директно с елементите на масива, който използваме като източник на данни, а не с тяхно свойство. При това свързване текстовата контрола ще се свърже първоначално с първия елемент от масива (символния низ "София"), но след това програмно може да се укаже промяна на текущия елемент и свързването да се промени към някой друг от елементите на масива. На начините за промяна на текущия елемент на свързването ще се спрем след малко.

Свързване на контрола към таблица

Нека имаме DataSet обект ds с таблица Towns с колони id и name и TextBox контрола с име TextBoxTowns. Свързването на свойството Text на TextBox контролата към колоната name от таблицата може да се извърши по следния начин:

// Create a DataTable with columns id and name

DataTable towns = new DataTable("Towns");

towns.Columns.Add(new DataColumn("id", typeof(int)));

towns.Columns.Add(new DataColumn("name", typeof(string)));

// Add three rows to the table

DataRow row;

row = towns.NewRow();

row["id"] = 1;

row["name"] = "София";

towns.Rows.Add(row);

row = towns.NewRow();

row["id"] = 2;

row["name"] = "Пловдив";

towns.Rows.Add(row);

row = towns.NewRow();

row["id"] = 3;

row["name"] = "Варна";

towns.Rows.Add(row);

// Create a DataSet and add the table to the DataSet

DataSet ds = new DataSet();

ds.Tables.Add(towns);

TextBoxTowns.DataBindings.Add(

new Binding("Text", ds, "Towns.name"));

За да укажем, че искаме да свържем свойството Text на TextBox контролата с колоната name на таблицата Towns от източника на данни ds, задаваме "Towns.name" за път до свойството на източника. Текстовото поле ще бъде свързано първоначално с първия ред на таблицата, и по-точно с полето name от този ред, но по-късно текущият ред може да бъде променен програмно.

Просто свързване с VS.NET

Свързването може да става и по време на дизайн в редактора на VS.NET, ако за източник на данни използваме DataSet. За целта от прозореца Properties на редактора избираме Databindings | Advanced. Появява се прозорецът Advanced Data Binding. В него виждаме списък от свойствата на контролата. Намираме свойството, за което искаме да добавим свързване, и от падащия списък в дясно от него избираме източника на данни.

Свързване на контрола към обект – пример

С настоящия пример ще илюстрираме простото свързване (simple binding) в Windows Forms. За целта ще създадем просто приложение, в което ще свържем свойство на контрола със свойство на даден обект.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Binding Control To Object". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Дефинираме клас Customer, с чийто обект ще свържем по-късно контролата. Класът има свойство Name, даващо достъп до името на клиента:

class Customer

{

private string mName;

public string Name

{

get { return mName; }

set { mName = value; }

}

4. Добавяме в класа MainForm една член-променлива mCustomer. С нея ще свържем текстово поле във формата.

private Customer mCustomer;

5. В главната форма поставяме една TextBox контрола с име TextBoxCustomerName, която ще свържем с Customer обекта и три бутона с имена ButtonShowCustomer, ButtonChangeCustomer и ButtonRebind. Тези бутони ще служат съответно за показване на името на клиента, за промяна на името и за извършване на свързване (data binding) на текстовото поле с Customer обекта.

6. В класа MainForm добавяме функция RebindFormControls(), която свързва свойството Text на текстовата контрола със свойството Name на Customer обекта. За целта първо свързването се изтрива (в случай, че е било вече създадено) и след това се добавя отново:

private void RebindFormControls()

{

TextBoxCustomerName.DataBindings.Clear();

TextBoxCustomerName.DataBindings.Add(

new Binding("Text", mCustomer, "Name"));

}

7. Добавяме код, който при зареждане на формата (при събитие Load на формата) да инициализира Customer обекта и да го свърже с текстовата контрола:

private void MainForm_Load(object sender, System.EventArgs e)

{

mCustomer = new Customer();

mCustomer.Name = "Бай Иван";

RebindFormControls();

}

8. Добавяме обработчик на събитието Click на ButtonShowCustomer бутона. В него извличаме стойността на полето Name на Customer обекта и я показваме в диалогова кутия:

private void ButtonShowCustomer_Click(object sender,

System.EventArgs e)

{

string customerName = mCustomer.Name;

MessageBox.Show(customerName);

}

9. Добавяме обработчик на събитието Click на ButtonChangeCustomer бутона. В него променяме стойността на полето Name на Customer обекта:

private void ButtonChangeCustomer_Click(object sender,

System.EventArgs e)

{

mCustomer.Name = "Дядо Мраз";

}

10. Добавяме обработчик на събитието Click на бутона ButtonRebind. В него извикваме функцията RebindFormControls(), която извършва повторно свързване на текстовата контрола с името на клиента от Customer обекта, при което това име се появява в контролата:

private void ButtonRebind_Click(object sender,

System.EventArgs e)

{

RebindFormControls();

}

11. Приложението вече е готово и можем да го стартираме и тестваме.

Ако въведем стойност в полето и натиснем първия бутон, в диалоговата кутия ще се покаже въведената стойност. Това показва, че стойността се е прехвърлила в Customer обекта:

Ако натиснем втория бутон, стойността в Customer обекта ще се промени. Това можем да проверим като натиснем първия бутон и изведем стойността в диалогова кутия. Въпреки че стойността в Customer обекта е променена, текстовото поле не се променя. Това е така, защото свързването в Windows Forms е еднопосочно – от контролата към свързвания обект, но не и обратно.

Ако сега натиснем третия бутон, текстовото поле ще се промени. Това е така, защото извършваме повторно свързване и името на клиента от Customer обекта се прехвърля в текстовото поле.

Binding Context

Формата пази информация за свързаните контроли в своя BindingContext обект. Всеки обект, наследен от класа Control, има един BindingContext, който управлява BindingContextBase обектите за контролите, които се съдържат в него и за самия обект. Чрез него можем да извлечем BindingContextBase обект за източник на данни, свързан с някоя контрола.

Понеже BindingContextBase е абстрактен клас, типът на върнатата стойност, в зависимост от източника на данни, е или CurrencyManager или PropertyManager, които са наследници на класа BindingContextBase. Ако източникът на данни е обект, който връща само една стойност (не е списък от обекти), тогава типът ще бъде PropertyManager. Ако източникът на данни имплементира някой от интерфейсите IList, IListSource или IBindingList, ще бъде върнат CurrencyManager.

На следващата фигура са показани схематично отношенията между Binding Context, Currency Manager и Property Manager:

Навигация с CurrencyManager

Класът CurrencyManager пази текущата позиция в списъка-източник на данни. Тя се съдържа в свойството Position. Свойството Count съдържа размера на списъка. Използвайки тези свойства, можем да извършваме навигация по източника на данни. За целта извличаме CurrencyManager обекта, свързан с източника на данни и променяме стойността на свойството Position.

Извличането на CurrencyManager обекта се извършва или чрез свойството DataBindings на свързаната контрола, или чрез BindingContext свойството на формата:

CurrencyManager cm = (CurrencyManager)

textBox1.DataBindings["Text"].BindingManagerBase;

// Може и така:

CurrencyManager cm = (CurrencyManager)

form1.BindingContext[dataTableCustomers];

Навигацията по списъка се извършва чрез промяна на Position:

cm.Position++;

Свързване на контрола към списък и навигация – пример

С настоящия пример ще илюстрираме просто свързване (simple binding) на контрола към списък и навигация по списъка чрез CurrencyManager.

Ето стъпките за изграждане на приложението:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Binding Control To List". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Поставяме върху главната форма една TextBox контрола с име TextBoxTowns, която ще свържем с масив от символни низове - имена на градове, и два бутона с имена ButtonPrev и ButtonNext. Тези бутони ще служат съответно за навигация напред и назад по списъка с градовете. На свойството Text на двата бутона задаваме съответно стойности "<< Prev" и "Next >>".

4. Добавяме код, който при зареждане на формата (при събитие Load на формата) свързва текстовото поле с масив, съдържащ имена на градове:

private void MainForm_Load(object sender, System.EventArgs e)

{

string[] towns = {"София", "Пловдив", "Варна",

"Русе", "Бургас"};

TextBoxTowns.DataBindings.Add(

new Binding("Text", towns, ""));

}

5. Добавяме обработчик на събитието Click на бутона ButtonPrev. В него извличаме от CurrencyManager обекта на текстовата контрола текущата позиция в списъка с градовете и я намаляваме, като, ако сме достигнали началото, позиционираме в края:

private void ButtonPrev_Click(object sender, System.EventArgs e)

{

CurrencyManager cm = (CurrencyManager)

TextBoxTowns.DataBindings["Text"].BindingManagerBase;

if (cm.Position > 0)

{

cm.Position--;

}

else

{

cm.Position = cm.Count-1;

}

6. Добавяме обработчик на събитието Click на бутона ButtonNext. В него извличаме от CurrеncyManager на текстовата контрола текущата позиция в списъка с градовете и я увеличаваме, като, ако сме достигнали края, позиционираме в началото:

private void ButtonNext_Click(object sender, System.EventArgs e)

{

CurrencyManager cm = (CurrencyManager)

TextBoxTowns.DataBindings["Text"].BindingManagerBase;

if (cm.Position < cm.Count-1)

{

cm.Position++;

}

else

{

cm.Position = 0;

}

7. Приложението е готово и можем да го стартираме и тестваме.

При натискане на бутоните в текстовото поле ще се сменят имената на градовете. Ако променим името на някой град, промяната се отразява в масива с имената.

Сложно свързване

При сложното свързване имаме свързване на контрола към списък, като контролата се свързва с повече от един елемент от списъка. Сложното свързване се използва при списъчни контроли – ListBox, ComboBox и др.

За да свържем списъчна контрола със списък, трябва да зададем стойности на следните свойства:

- DataSource – източника на данни, с който ще свържем контролата.

- DisplayMember – път до полето, което да се визуализира.

- ValueMember – път до полето, от което се получава резултатът.

Стойността по подразбиране в DisplayMember и ValueMember е празен низ.

Ето как задаваме стойност на тези свойства:

DataSet dataSetCountries = ...;

comboBox1.DataSource = dataSetCountries;

comboBox1.DisplayMember = "Countries.CountryCode";

comboBox1.ValueMember = "Countries.Name";

Сложно свързване на контрола към списък – пример

С настоящия пример ще илюстрираме сложното свързване (complex data binding) в Windows Forms. За целта ще създадем просто приложение, в което ще свържем списъчна контрола със списък.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Complex Binding". Променяме името на файла от Form1.cs на MainForm.cs.

3. Поставяме във формата един бутон с име ButtonShow и една ComboBox контрола с име ComboBoxTowns. На свойството Text на бутона задаваме стойност Show. ComboBox контролата ще свържем с масив от символни низове - имена на градове, а чрез бутона ще показваме стойността, избрана в нея.

4. Добавяме код, който при зареждане на формата (при събитие Load) свързва ComboBox контролата с масив, съдържащ имена на градове:

private void MainForm_Load(object sender, System.EventArgs e)

{

string[] towns = {"София", "Пловдив", "Варна",

"Русе", "Бургас"};

ComboBoxTowns.DataSource = towns;

ComboBoxTowns.DisplayMember = "";

}

5. Добавяме обработчик на събитието Click на бутона ButtonShow. В него показваме в диалогова кутия стойността, избрана в ComboBox контролата:

private void ButtonShow_Click(object sender, System.EventArgs e)

{

MessageBox.Show(ComboBoxTowns.SelectedValue.ToString());

}

6. Приложението ни е готово и можем да го стартираме и тестваме.

Сложно свързване с VS.NET

Сложното свързване може да става и по време на дизайн в редактора на VS.NET, ако за източник на данни използваме DataSet. За целта в прозореца Properties на редактора щракваме върху падащия списък от дясно на свойството DataSource и избираме от него източник на данни. След това избираме от падащите списъци в дясно от свойствата DisplayMember и ValueMember полето, което ще се визуализира, и полето, от което ще се получава резултатът:

Контролата DataGrid

DataGrid контролата визуализира таблични данни. Тя осигурява навигация по редове и колони и позволява редактиране на данните. Като източник на данни най-често се използват ADO.NET DataSet и DataTable. Чрез свойството DataSource се задава източникът на данни, а чрез свойството DataMember – пътят до данните в рамките на източника. По-важни свойства на контролата са:

- ReadOnly – разрешава / забранява редакцията на данни.

- CaptionVisible – показва / скрива заглавието.

- ColumnHeadersVisible – показва / скрива заглавията на колоните.

- RowHeadersVisible – показва / скрива колоната в ляво от редовете.

- TableStyles – задава стилове за таблицата.

o MappingName – задава таблицата, за която се отнася дефинираният стил.

o GridColumnStyles – задава форматиране на отделните колони – заглавие, ширина и др.

Противно на очакванията контролата DataGrid няма събитие "смяна на текущия избран ред". Ако ви се налага да извършвате някакво действие при смяна на текущия избран ред (например да запишете промените по текущия ред в базата данни), можете да прихванете събитието CurrentCellChanged, което се активира при промяна на текущата клетка. Ако запомните в член-променлива в класа на формата коя е била предишната текуща клетка, ще можете да проверите дали текущият ред е бил променен. Текущата клетка е достъпна от свойството CurrentCell.

Препоръчителен начин за използване на DataGrid контролата е в режим ReadOnly=true. В този случай не се разрешават директни промени, а това спестява много проблеми. Ако е необходимо редактиране на редове или добавяне на нови, това може да се направи с отделен диалогов прозорец, който излиза при натискане на бутон "Edit" или "Add" при избран ред от таблицата.

Работа с DataGrid контролата – пример

С настоящия пример ще илюстрираме работата с DataGrid контролата в Windows Forms и сложното свързване (complex data binding) на таблица от DataSet с DataGrid.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "DataGrid Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Поставяме във формата една DataGrid контрола. За име на контролата задаваме DataGridTowns.

4. Добавяме код, който при зареждане на формата (при събитие Load) създава DataSet, съдържащ таблица Towns с две колони – id и име на град. След като той e създаден, свързваме DataGrid контролата с таблицата Towns от този DataSet:

private void MainForm_Load(object sender, System.EventArgs e)

{

// Create table "Towns"

DataTable towns = new DataTable("Towns");

towns.Columns.Add(new DataColumn("id", typeof(int)));

towns.Columns.Add(new DataColumn("name", typeof(string)));

// Add some rows in the table

DataRow row = towns.NewRow();

row["id"] = 1;

row["name"] = "София";

towns.Rows.Add(row);

row = towns.NewRow();

row["id"] = 2;

row["name"] = "Пловдив";

towns.Rows.Add(row);

row = towns.NewRow();

row["id"] = 3;

row["name"] = "Варна";

towns.Rows.Add(row);

row = towns.NewRow();

row["id"] = 4;

row["name"] = "Русе";

towns.Rows.Add(row);

// Add table "Towns" to the DataSet

DataSet ds = new DataSet();

ds.Tables.Add(towns);

// Bind the DataGrid to the DataSet

DataGridTowns.DataSource = ds;

DataGridTowns.DataMember = "Towns";

}

5. Приложението е готово и можем да го стартираме и тестваме.

Ако променим данните, визуализирани в DataGrid контролата, те ще се променят и в таблицата Towns от DataSet обекта.

TableStyles и дефиниране на стилове – пример

Настоящият пример илюстрира работата с DataGrid контролата в Windows Forms и възможностите за дефиниране на стилове за визуализацията на данните чрез колекцията TableStyles. Ще създадем просто приложение, подобно на това от предходния пример, но чрез колекцията TableStyles ще определим как да бъдат визуализирани колоните на таблицата.

Ето и стъпките за изграждане на нашето приложение:

1. Началните стъпки за изграждане на приложението са същите като стъпки от 1 до 4 в предишния пример. Изпълняваме ги и преминаваме към дефинирането на стиловете за визуализация на данните.

2. Щракваме с десния бутон на мишката върху поставения в главната форма DataGrid и избираме Properties. В прозореца Properties на редактора избираме свойството TableStyles и щракваме върху бутона с многоточието, намиращ се в полето в дясно от него. Отваря се прозорец, който ни позволява да добавяме стилове за таблицата. Щракваме върху бутона Add, за да добавим нов стил. В дясната половина на прозореца можем да променяме свойствата на добавения стил. Намираме свойството Name и му задаваме стойност DataGridTableStyleTowns.

3. На свойството MappingName задаваме стойност Towns. С това указваме, че този стил се отнася за таблицата Towns. Задаваме на свойството AlternatingBackColor (указващо цвят, в който ще се оцветяват четните редове) стойност Info. Остана да зададем стилове за отделните колони.

4. Щракваме върху бутона с многоточието, намиращ се в полето в дясно от свойството GridColumnStyles. Отваря се прозорец, който ни позволява да добавяме стилове за отделните колони. Щракваме върху бутона Add, за да добавим нов DataGridTextBoxColumn в колекцията. Задаваме стойност DataGridTextBoxColumnName на свойството Name.

5. Задаваме на свойството MappingName стойност name. Така указваме, че този стил се отнася за полето name. Задаваме на свойствата Alignment, HeaderText и NullText съответно стойности Center, "име на град" и "(няма данни)". Така заглавието на колоната ще е "име на град", текстът ще е центриран, а когато няма стойност в полето, в таблицата ще се визуализира "(няма данни)". Накрая указваме ширина на колоната, като на свойството width зададем стойност 200.

6. Натискаме бутона [OK], за да запазим промените в колекцията със стиловете за колоните. След това натискаме бутона [OK] и в другия прозорец, за да запазим промените в стиловете за таблиците.

7. Приложението е готово и можем да го стартираме и тестваме.

Забелязваме, че макар в таблицата Towns да има две колони, в нашия DataGrid се визуализира само едната. Това е така, защото се визуализират само полетата, за които са добавени стилове в колекцията GridColumnStyles. Това означава, че ако не искаме дадено поле да бъде визуализирано, просто не указваме стил за него.

Ще отбележим, че когато добавяме стил в колекцията GridColumnStyles, освен DataGridTextBoxColumn, можем да добавяме и DataGridBoolColumn. Това става, като щракнем върху стрелката, намираща се в дясната част на бутона Add, и от падащия списък изберем DataGridBoolColumn. Чрез DataGridBoolColumn определяме колона, която във всяка клетка съдържа поле с отметка, представящо булева стойност.

Master-Details навигация

Навигацията "главен/подчинен" (master-details) отразява взаимоотношения от тип едно към много (например един регион има много области). В ADO.NET DataSet обектите поддържат релации от тип "главен/подчинен". За целта се използват DataRelation обектите в DataSet.

В Windows Forms се поддържа навигация "главен/подчинен". За да илюстрираме работата с нея, нека разгледаме един пример: Имаме DataSet, съдържащ две таблици – едната съдържа имена на държави, а другата – имена на градове. Те са свързани помежду си така, че на всяка държава от първата таблица съответстват определени градове от втората таблица:

Тогава можем да използваме две DataGrid контроли – първата, визуализираща държавите, а втората, визуализираща градовете, съответстващи на текущо избраната държава от първата контрола. За целта контролите се свързват с един и същ DataSet. На главната контрола се задава за източник на данни главната таблица. На подчинената контрола се задава за източник на данни релацията на таблицата:

// Bind the master grid to the master table

DataGridCountries.DataSource = datasetCountriesAndTowns;

DataGridCountries.DataMember = "Countries";

// Bind the detail grid to the relationship

DataGridTowns.DataSource = datasetCountriesAndTowns;

DataGridTowns.DataMember = "Countries.CountriesTowns";

Master-Details навигация – пример

Настоящият пример илюстрира възможностите за реализация на Master-Details навигация, базирана на DataSet компонентата от ADO.NET и сложното свързване на списъчни контроли в Windows Forms. В примера ще използваме базата данни Northwind – една от стандартните демонстрационни бази в MS SQL Server.

Ще създадем приложение, което има в главната си форма две контроли – ListBox, който показва региони (от таблицата Region от базата данни), и DataGrid, който показва областите за всеки регион (от таблицата Territories от базата данни).

Ето и стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Master-Detail Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. В прозореца Server Explorer от VS.NET намираме демонстрационната база данни Northwind на MS SQL Server. Щракваме върху таблицата Region и след това, натискайки клавиш Ctrl, щракваме върху таблицата Territories. След като сме маркирали едновременно и двете таблици, ги извличаме върху формата. Ако прозорецът Server Explorer не е отворен, можем да го отворим, като изберем View | Server Explorer.

4. Windows Forms редакторът автоматично създава за нас един SqlConnection и два SqlDataAdapter компонента. Променяме техните имена съответно на sqlConneciton, sqlDataAdapterRegion и sqlDataAdapterTerritories:

5. От менюто Data избираме Generate Dataset… В появилия се прозорец указваме, че искаме да създадем нов DataSet и задаваме за име DataSetNorthwind. Поставяме отметки и пред двете таблици и натискаме бутона [OK], за да създадем новия DataSet. Променяме името на появилия се в редактора DataSet на dataSetNorthwind.

6. Щракваме с десния бутон върху dataSetNorthwind в редактора и от появилото се контекстно меню избираме View Schema… Отваря се файлът DataSetNorthwind.xsd - виждаме XSD схемата на DataSet-a, генериран на базата на таблиците Region и Territories.

7. От Toolbox извличаме един Relation обект и го пускаме върху таблицата Territories. В появилия се прозорец се уверяваме, че за Parent element e избрана таблицата Region, а за Child element - таблицата Territories, и натискаме бутона OK. Така дефинирахме релация тип Master-Details между таблиците Region и Territories.

8. Добавяме във формата един ListBox с име ListBoxRegions. На свойството DataSource задаваме стойност dataSetNorthwind, а на свойствата DisplayMember и ValueMember – съответно стойности Region.RegionDescription и Region.RegionID.

9. Добавяме във формата един DataGrid с име DataGridTerritories. Задаваме на свойствата DataSource и DataMember съответно стойности dataSetNorthwind и Region.RegionTerritories.

10. Дефинираме стил с име dataGridTableStyleTerritories за таблицата Territories. В колекцията му GridColumnStyles добавяме стилове за полетата TerritoryID и TerritoryDescription, като указваме, че тези колони трябва да са със заглавия - съответно код и област.

11. Добавяме код, който при зареждане на формата (при събитие Load) зарежда DataSet обекта от базата данни чрез DataAdapter компонентите за двете таблици (Region и Territories):

private void MainForm_Load(object sender, System.EventArgs e)

{

sqlDataAdapterRegion.Fill(dataSetNorthwind);

sqlDataAdapterTerritories.Fill(dataSetNorthwind);

}

12. Приложението е готово и можем да го стартираме и тестваме:

Проблеми при Master-Details навигацията

Показаният начин за реализация на master-details навигация е лесен за използване, но има един сериозен проблем: винаги зарежда в паметта всички записи от двете таблици. Ако таблиците са обемни, този подход ще работи много бавно или въобще няма да работи. Причината е, че зареждането на голям обем записи (да кажем няколко хиляди) в DataSet изисква много памет и става бавно.

Ако данните са много, можем да подходим по следния начин: Зареждаме всички данни от главната (master) таблица и ги визуализираме с DataGrid или ListBox. След това прихващаме събитието "смяна на текущия ред" и при неговото настъпване зареждаме в подчинената (details) таблица детайлните записи за избрания запис от главната таблица. Зареждането може да се извърши с параметрична SQL заявка, изпълнена през SqlDataReader или SqlDataAdapter.

Релации "много към много"

DataSet и DataGrid не поддържат релации тип "много към много". Такъв тип релации могат да бъдат сведени до Master-Details чрез добавяне на изглед в базата данни. Нека примерно имаме база данни, съдържаща таблици Courses и Students и таблица StudentsCourses, осъществяваща връзка между тях.

За да сведем тази релация към Master-Details, можем да създадем изглед в базата данни:

CREATE VIEW View_StudentsCourses AS

SELECT StudentId, StudentName, CourseId, CourseName

FROM Students, Courses, StudentsCourses

WHERE Students.StudentsId = StudentsCourses.StudentId

AND Courses.CourseId = StudentsCourses.CourseId

След като сме създали изгледа, можем да сведем релацията до релация Master-Details между таблицата Courses и новосъздадения изглед:

Аналогично на предходния пример можем да работим с таблиците, които са вече във взаимоотношение "главен/подчинен":

Наследяване на форми

Наследяването на форми позволява повторно използване на части от потребителския интерфейс. Чрез него е възможно да променим наведнъж общите части на много форми. За целта дефинираме една базова форма, която съдържа общата за всички наследници функционалност.

Базовата форма е най-обикновена форма. Единствената особеност е, че контролите, които могат да се променят от наследниците, се обявяват като protected. Виртуални методи могат да реализират специфичната за наследниците функционалност, достъпна от базовата форма.

При наследяване на форма се наследява класът на базовата форма. При това се указва името на пространството, в което е дефинирана базовата форма, следвано от точка, и името на базовата форма. Във Visual Studio .NET формите наследници могат да се създават, като от менюто се избере File | Add New Item… | Inherited Form.

При наследяването на форми можем да поставим базовата форма и формите-наследници в различни асемблита и след това да променяме всички форми-наследници чрез промяната на единичен DLL файл.

Една особеност на VS.NET е, че по време на дизайн промените, направени върху базовата форма, не се отразяват върху формите наследници, преди да бъде прекомпилирано приложението.

Наследяване на форми – пример

Настоящият пример илюстрира възможностите за наследяване на форми в Windows Forms, при което се наследяват всички контроли в тях, както и методите и свойствата на класа, в който са дефинирани. В примера ще създадем четири форми:

- MainForm – главната форма на приложението, която ще служи за показване на другите форми при натискане на съответния бутон.

- BaseForm – базова форма, от която други форми наследяват потребителски интерфейс и базова функционалност.

- AddressForm – форма за попълване на адрес, наследник на BaseForm.

- ItemsDetailsForm - форма за попълване на описание на продукт, наследник на BaseForm.

Схематично наследяването между формите е показано на фигурата по-долу:

Ето и стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Main Form". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Добавяме нова форма с име BaseForm. Това ще бъде нашата базова форма. От нея ще наследим останалите форми. В нея поставяме един Panel с име PanelMain и три бутона ButtonOK, ButtonCancel и ButtonReset. Дефинираме панела като protected, за да може да се променя от наследниците. Бутоните ButtonOK и ButtonCancel имат обичайното предназначение, което е зададено със свойствата AcceptButton и CancelButton на формата.

4. Добавяме обработчик на събитието Click на бутона ButtonReset. В него ще извикваме виртуалния метод ResetFormFields(), който трябва да се имплементира в наследниците и трябва да изтрива всички полета:

private void ButtonReset_Click(object sender,System.EventArgs e)

{

ResetFormFields();

}

5. Добавяме и виртуалния метод ResetFormFields():

protected virtual void ResetFormFields()

{

// Descendand form should implement reset functionality here

}

6. Компилираме приложението, за да се създаде асемблито, в което ще се съдържа формата, от която ще наследяваме. За целта избираме Build | Build Solution.

7. Добавяме първата форма-наследник. За целта избираме File | Add New Item… | Inherited Form. Въвеждаме за име на формата AddressForm и натискаме бутона open. От появилия се списък избираме BaseForm за компонент, от който ще наследяваме. Отваря се формата-наследник, която изглежда точно като базовата форма.

8. Променяме заглавието й на Address Form. Добавяме във формата един TextBox с име TextBoxAddress и две ComboBox контроли с имена ComboBoxTown и ComboBoxCountry. Задаваме на свойството Multiline на TextBoxAddress стойност true. За DropDownStyle на ComboBox контролите задаваме DropDownList. В колекцията Items на ComboBoxTowns въвеждаме няколко имена на български градове, а в тази на ComboBoxTowns въвеждаме "България".

9. Предефинираме метода ResetFormFields() така, че да изчиства полетата на формата:

protected override void ResetFormFields()

{

this.TextBoxAddress.Clear();

this.ComboBoxTown.SelectedIndex = -1;

this.ComboBoxCountry.SelectedIndex = -1;

}

10. Добавяме втората форма-наследник. Задаваме ItemDetailsForm за име на формата. Променяме заглавието й на Item Details Form. Добавяме във формата две TextBox контроли с имена TextBoxName и TextBoxPrice, един ComboBox с име ComboBoxCategory и един CheckBox с име ChackBoxAvailability. За DropDownStyle на ComboBoxCategory задаваме DropDownList, а в колекцията Items въвеждаме няколко категории – "Алкохол", "Безалкохолни напитки", "Колбаси", "Стоки за бита". Задаваме на свойството Text на ChackBoxAvailability стойност "Наличност".

11. Предефинираме и в тази форма метода ResetFormFields() така, че да изчиства полетата:

protected override void ResetFormFields()

{

this.TextBoxName.Clear();

this.TextBoxPrice.Clear();

this.ComboBoxCategory.SelectedIndex = -1;

this.CheckBoxAvailability.Checked = false;

}

12. Поставяме подходящи етикети на контролите във формите – например при TextBoxName поставяме етикет, чието свойство Text има стойност "Име на продукт:".

13. В главната форма добавяме два бутона с имена ButtonAddressForm и ButtonItemDetailsForm. В обработчиците на събитията Click на тези бутони ще показваме формите наследници:

private void ButtonAddressForm_Click(object sender,

System.EventArgs e)

{

AddressForm addressForm = new AddressForm();

addressForm.ShowDialog();

addressForm.Dispose();

}

private void ButtonItemDetailsForm_Click(object sender,

System.EventArgs e)

{

ItemDetailsForm itemDetailsForm = new ItemDetailsForm();

itemDetailsForm.ShowDialog();

itemDetailsForm.Dispose();

}

14. Приложението е готово и можем да го стартираме и тестваме:

Пакетът System.Drawing и GDI+

Пакетът System.Drawing осигурява достъп до GDI+ функциите на Windows:

- повърхности за чертане

- работа с графика и графични трансформации

- изчертаване на геометрични фигури

- работа с изображения

- работа с текст и шрифтове

- печатане на принтер

Той се състои от няколко пространства:

- System.Drawing – предоставя основни класове като повърхности, моливи, четки, класове за изобразяване на текст.

- System.Drawing.Imaging – предоставя класове за работа с изображения, картинки и икони, класове за записване в различни файлови формати и за преоразмеряване на изображения.

- System.Drawing.Drawing2D – предоставя класове за графични трансформации – бленди, матрици и др.

- System.Drawing.Text – предоставя класове за достъп до шрифтовете на графичната среда.

- System.Drawing.Printing – предоставя класове за печатане на принтер и системни диалогови кутии за печатане.

Класът Graphics

Класът System.Drawing.Graphics предоставя абстрактна повърхност за чертане. Такава повърхност може да бъде както част от контрола на екрана, така и част от страница на принтер или друго устройство.

Най-често чертането се извършва в обработчика на събитието Paint. В него при необходимост се преизчертава графичния облик на контролата. Параметърът PaintEventArgs, който се подава, съдържа Graphics обекта. Graphics обект може да се създава чрез Control.CreateGraphics(). Той задължително трябва да се освобождава чрез finally блок или с конструкцията using, защото е ценен ресурс.

Работа със System.Drawing – пример

Чрез настоящия пример ще илюстрираме работата с GDI+ чрез пакета System.Drawing – чертане на геометрични фигури с четки и моливи и изобразяване на текст със зададен шрифт.

Ето и стъпките за изграждане на нашето примерно приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и подходящо заглавие, например "System.Drawing Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Добавяме обработчик на събитието Paint, където изчертаваме графично изображение:

private void MainForm_Paint(object sender,

System.Windows.Forms.PaintEventArgs e)

{

Graphics g = e.Graphics;

g.SmoothingMode = SmoothingMode.AntiAlias;

Brush brush = new SolidBrush(Color.Blue);

g.FillEllipse(brush, 50, 40, 350, 250);

brush.Dispose();

Pen pen = new Pen(Color.Red, 2);

g.DrawRectangle(pen, 40, 50, 200, 40);

pen.Dispose();

brush = new SolidBrush(Color.Yellow);

Font font = new Font("Arial", 14, FontStyle.Bold);

g.DrawString(".NET Framework", font, brush, 60, 60);

brush.Dispose();

font.Dispose();

}

В метода вземаме Graphics обекта на формата, създаваме подходящи четки, моливи и шрифтове. С тях изчертаваме запълнена елипса и правоъгълник и в него изписваме текст. Всички GDI+ ресурси (четки, моливи и шрифтове) задължително се освобождават след използване.

4. Приложението е готово и можем да го стартираме и тестваме:

Анимация със System.Drawing – пример

Настоящият пример илюстрира как със средствата на GDI+ чрез пакета System.Drawing може да се реализира плавна анимация на някакъв геометричен обект.

Ето и стъпките за изграждане на нашето примерно приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "System. Drawing Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Добавяме променливи и константи за позицията на анимирания обект (елипса), стъпката на преместване и размерите на елипсата:

private int mPosX = 0;

private int mPosY = 0;

private int StepX = 1;

private int StepY = 1;

public const int ELLIPSE_SIZE_X = 70;

public const int ELLIPSE_SIZE_Y = 40;

4. Поставяме в главната форма една Timer компонента с име TimerAnimaiton и един PictureBox с име PictureBoxAnimatoin.

5. Добавяме обработчик на събитието Paint на PictureBox контролата. В него изчертаваме движещия се обект на позицията, в която се намира в момента:

private void PictureBoxAnimation_Paint(object sender,

System.Windows.Forms.PaintEventArgs e)

{

Graphics g = e.Graphics;

g.SmoothingMode = SmoothingMode.AntiAlias;

Brush brush = new SolidBrush(Color.Blue);

g.FillEllipse(brush, mPosX, mPosY,

ELLIPSE_SIZE_X, ELLIPSE_SIZE_Y);

brush.Dispose();

brush = new SolidBrush(Color.Yellow);

Font font = new Font("Arial", 14, FontStyle.Bold);

g.DrawString(".NET", font, brush, mPosX+10, mPosY+10);

brush.Dispose();

font.Dispose();

}

6. Задаваме на свойствата Enabled и Interval на Timer компонентата съответно стойности true и 10. Така тя ще генерира събитие на всеки 10 милисекунди.

7. Добавяме обработчик на събитието Elapsed на Timer компонентата. В него променяме координатите на движещия се обект и пречертаваме PictureBox контролата:

private void TimerAnimation_Elapsed(object sender,

System.Timers.ElapsedEventArgs e)

{

mPosX += StepX;

if ((mPosX >= PictureBoxAnimation.Width - ELLIPSE_SIZE_X - 3)

|| (mPosX <= 0))

{

StepX = -StepX;

}

mPosY += StepY;

if ((mPosY >= PictureBoxAnimation.Height - ELLIPSE_SIZE_Y - 3)

|| (mPosY <= 0))

{

StepY = -StepY;

}

PictureBoxAnimation.Refresh();

}

8. Приложението е готово и можем да го стартираме и тестваме:

В примера сме използвали PictureBox контрола, защото тя не чертае нищо в своя Paint метод, който се извиква преди всяко пречертаване. Ако бяхме използвали Panel или друга контрола, щеше да се получи трепкане.

За професионална анимация се използва DirectX технологията, която използва ресурсите на графичната карта много по-ефективно и натоварва централния процесор много по-малко. Като цяло за по-сложни приложения (например игри) използваният в този пример подход е грешен!

Печатане на принтер

Често се налага създадените от нас приложения да отпечатват някаква информация на принтер. Пространството System.Drawind.Printing ни предоставя класове, чрез които можем да реализираме такава функционалност.

При печатането на принтер се използват три ключови класа:

- PrintDialog – стандартен диалог за печатане на принтер. Позволява на потребителя да избере принтер и да укаже кои части от документа да се отпечатат.

- PrintController – управлява процеса на печатане и активира събития, свързани с него. PrintController предоставя Graphics повърхността, върху която печатаме.

- PrintDocument – описва характеристиките на отпечатвания документ. Съдържа PrinterSettings, върнати от PrintDialog.

Обикновено, когато искаме да отпечатаме нещо на принтер, създаваме инстанция на класа PrintDocument, задаваме стойности на свойствата, описващи какво ще печатаме, и извикваме метода Print(), за да отпечатаме документа.

Потребителски контроли

Потребителските контроли (custom controls) позволяват разширяване на стандартния набор от контроли чрез комбиниране на съществуващи контроли, разширяване на съществуващи или създаване на съвсем нови такива.

Потребителските контроли или разширяват съществуващи контроли, или класа Control или класа UserControl. Те могат да управляват поведението си по време на изпълнение, както и да взаимодействат с дизайнера на VS.NET по време на дизайн.

Създаване на нова контрола, която не наследява съществуваща

Създаването на нова контрола, която не наследява никоя съществуваща вече контрола, става по следния начин:

1. От VS.NET избираме File | Add New Item … | UI | Custom Control.

2. Припокриваме виртуалния метод Paint(…), за да чертаем графичния образ на контролата.

3. Дефинираме необходимите свойства и методи.

4. Обявяваме свойствата, достъпни от дизайнера на средата за разработка (VS.NET) чрез следните атрибути:

- Category – указва категорията, в която ще се показва свойството.

- Description – задава описание на свойството.

Създаване на нова контрола като комбинация от други контроли

Създаването на контрола като комбинация от други контроли става по следния начин:

1. От VS.NET избираме File | Add New Item … | UI | User Control.

2. Използваме дизайнера на VS.NET, за да добавим контроли и да оформим желания вид на контролата.

3. Обявяваме свойствата, достъпни за дизайнера на средата за разработка чрез атрибутите Category и Description.

Създаване на нова контрола, която наследява съществуваща контрола

Създаването на нова контрола, която наследява съществуваща контрола, става по следния начин:

1. От VS.NET избираме File | Add New Item … | UI | Inherited User Control.

2. Избираме контролата, от която ще наследяваме.

3. Дефинираме допълнителни методи и свойства и ги обявяваме за дизайнера на VS.NET чрез атрибутите Category и Description.

4. Припокриваме OnXXX() методите при необходимост, за да променим поведението на оригиналната контрола.

Създаване на контрола – пример

В настоящия пример ще илюстрираме как със средствата на Windows Forms и GDI+ можем да създаваме потребителски Windows Forms контроли. Ще създадем контролата ClockControl, която представлява кръгъл часовник със стрелки, на който може да се задава колко часа да показва.

Ето стъпките за създаване на контролата и на приложение, което я използва:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Clock Control Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Създаваме нашата потребителска контрола. За целта избираме File | Add New Item … | UI | Custom Control. Задаваме ClockControl за име на контролата.

4. Дефинираме две полета mHour и mMinute и свойства за достъп до тях. Те ще съдържат часа и минутите на нашия часовник:

private int mHour;

private int mMinute;

[Category("Behavior"), Description("Specifies the hour.")]

public int Hour

{

get

{

return mHour;

}

set

{

mHour = value;

this.Invalidate();

}

[Category("Behavior"), Description("Specifies the minutes.")]

public int Minute

{

get

{

return mMinute;

}

set

{

mMinute = value;

this.Invalidate();

}

Приложили сме към свойствата атрибути Category и Description, за да укажем на Visual Studio .NET да ги публикува в Properties прозореца по време на дизайн. При промяна на свойствата се извиква методът Invalidate(), за да се пречертае контролата и да се преместят стрелките на часовника.

5. Добавяме една константа за размер по подразбиране и добавяме в конструктора код за инициализиране на контролата. Ще инициализираме контролата с текущия час:

private const int DEFAULT_SIZE = 100;

public ClockControl()

{

// This call is required by the Windows.Forms Form Designer.

InitializeComponent();

this.Size = new Size(DEFAULT_SIZE, DEFAULT_SIZE);

mHour = DateTime.Now.Hour;

mMinute = DateTime.Now.Minute;

}

6. Припокриваме виртуалния метод OnPaint(…) и в него чертаем часовника върху Graphics повърхността на контролата. За пресмятане на координатите на стрелките използваме изчисления с помощта на тригонометрични функции синус и косинус:

protected override void OnPaint(PaintEventArgs pe)

{

Graphics g = pe.Graphics;

// Draw the circle

Pen pen = new Pen(Color.Blue, 1);

g.DrawEllipse(pen, 0, 0, this.Width-1, this.Height-1);

pen.Dispose();

// Draw the minute finger

double minuteFingerAngle =

(mMinute % 60) * (2*Math.PI/60);

int minuteFingerLen = this.Width * 45 / 100;

int x1 = this.Width / 2;

int y1 = this.Height / 2;

int x2 = (int) (x1 +

minuteFingerLen*Math.Sin(minuteFingerAngle));

int y2 = (int) (y1 –

minuteFingerLen*Math.Cos(minuteFingerAngle));

pen = new Pen(Color.Red, 2);

g.DrawLine(pen, x1, y1, x2, y2);

pen.Dispose();

// Draw the hour finger

double hourFingerAngle =

(mHour % 12) * (2*Math.PI/12) +

(mMinute % 60) * (2*Math.PI/(60*12));

int hourFingerLen = this.Width * 25 / 100;

x1 = this.Width / 2;

y1 = this.Height / 2;

x2 = (int) (x1 + hourFingerLen*Math.Sin(hourFingerAngle));

y2 = (int) (y1 - hourFingerLen*Math.Cos(hourFingerAngle));

pen = new Pen(Color.Yellow, 3);

g.DrawLine(pen, x1, y1, x2, y2);

pen.Dispose();

// Calling the base class OnPaint

base.OnPaint(pe);

}

7. Припокриваме метода OnSize(…), в който приравняваме височината и ширината на контролата и я пречертаваме. Така контролата винаги ще бъде с квадратна форма:

protected override void OnResize(System.EventArgs e)

{

this.Height = this.Width;

this.Invalidate();

}

8. Нашата потребителска контрола е готова. Можем да прекомпилираме приложението и да я добавим в Toolbox. За да я добавим в Toolbox, щракваме в него с десен бутон на мишката и от там избираме Add/Remove Items… В появилия се прозорец натискаме бутона Browse… и избираме изпълнимия файл на нашето приложение. Поставяме отметка пред ClockControl в списъка и натискаме бутона OK. Контролата се добавя в Toolbox.

9. В главната форма на приложението поставяме една ClockControl контрола с име clock и един панел с контроли за промяна на текущия час и минути – две NumericUpDown контроли с имена NumericUpDownHour и NumericUpDwonMinute и един бутон с име ButtonSetTime за отразяване на промените. Свойствата на ClockControl могат да бъдат променяни от прозореца Properties (вж. фигурата по-горе).

10. Добавяме код, който при зареждане на формата (при събитие Load на формата) задава стойностите на NumericUpDown контролите за час и минута, съответстващи на тези от ClockControl обекта:

private void MainForm_Load(object sender, System.EventArgs e)

{

NumericUpDownHour.Value = clock.Hour;

NumericUpDownMinute.Value = clock.Minute;

}

11. Добавяме обработчик на събитието Click на ButtonSetTime. В него променяме стойностите на свойствата на ClockControl обекта:

private void ButtonSetTime_Click(object sender,

System.EventArgs e)

{

clock.Hour = (int) NumericUpDownHour.Value;

clock.Minute = (int) NumericUpDownMinute.Value;

}

12. Добавяме обработчик на събитието SizeChanged на формата. В него добавяме код, който не позволява на часовника да бъде върху панела:

private void MainForm_SizeChanged(object sender,

System.EventArgs e)

{

ClientSize = new Size(

ClientSize.Width, ClientSize.Width + PanelDown.Height);

}

13. Приложението е готово и можем да го стартираме и тестваме.

Хостинг на контроли в Internet Explorer

Internet Explorer може да изпълнява Windows Froms контроли, вградени в тялото на HTML страници. Технологията е подобна на Java аплетите и Macromedia Flash – вгражда се изпълним код, който се изпълнява в клиентския уеб браузър. От JavaScript могат да се достъпват свойствата на Windows Forms контролите. Необходими са Internet Explorer 5.5, или по-нова версия, и инсталиран .NET Framework.

Настройките за сигурност не позволяват достъп до файловата система и други опасни действия. Сигурността може да се задава и ръчно. Ако има нужда от запазване на някакви данни на машината на потребителя, може да се използва Isolated Storage.

Хостинг на контроли в Internet Explorer – пример

Настоящият пример илюстрира как можем да реализираме хостинг на Windows Forms контроли в Internet Explorer чрез вграждането им в HTML страница и как можем да достъпваме свойствата им от JavaScript.

Да разгледаме примерна HTML страница, в която е вградена Windows Forms контролата "часовник" от предходния пример:

index.html

<html>

function ChangeText() {

clockControl.Hour = hour.value;

clockControl.Minute = minute.value;

}

</script>

<body>

<p>Clock Control in IE</p>

classid="http:Demo-18-CustomControl-Clock.exe#Demo_18_CustomControl_Clock.ClockControl"

width="200" height="200">

</object>

<br>

Hour:<input type="text" id="hour"><br>

Minute:<input type="text" id="minute"><br>

</body>

</html>

Как работи примерът?

Нека разгледаме по-подробно отделните части на HTML страницата. Чрез HTML тага <object> вмъкваме в страницата нашата контрола. Това е часовникът, който създадохме в предишния пример. Атрибутът id, който има стойност clockContol, указва идентификатор, чрез който ще можем да достъпваме обекта в HTML страницата, а атрибутите width и height указват с каква ширина и височина да се изобрази той. Атрибутът classid определя класа на вмъквания обект. В случая това е нашата ClockControl контрола. Забележете, че указваме асемблито, пространството и името на класа в стойността на този атрибут. В случая сме поставили асемблито Demo-18-CustomControl-Clock.exe в директорията, в която се намира и HTML страницата. Чрез таговете <param> задаваме стойности за свойствата на изобразяваната контрола.

Под контролата сме поставили две текстови полета и един бутон. Текстовите полета служат за въвеждане на час и минути, които да показва часовникът. Бутонът служи за промяна на стрелките на часовника. При натискането му се извиква JavaScript функцията ChangeText(), дефинирана в началото на страницата, която променя свойствата на контролата. Достъпът до текстовите полета и до контролата се извършва посредством техните идентификатори, зададени чрез атрибута id.

Примерът в действие

За да видим резултата от нашата работа, трябва да използваме Internet Explorer 5.5 или по-нов. Не е известен друг уеб браузър, който поддържа Windows Forms контроли.

Ако отворим директно index.html в Internet Explorer, контролата ClockControl няма да се зареди заради политиката за сигурност, която не позволява локално разположени HTML документи да изпълняват Windows Forms контроли. Необходимо е страницата да бъде публикувана на някакъв уеб сървър, например IIS.

Нека файловете ни се намират в папката Demo-19-Custom-Controls-in-IE. Публикуването на папката в Internet Information Services (IIS) се извършва по следния начин:

1. От свойствата на папката Demo-19-Custom-Controls-in-IE, достъпни от диалоговата кутия на Windows Explorer, избираме таба "Web Sharing". В него избираме "Share this folder".

2. Публикуваме папката Internet Information Services, като позволим четене на файловете и листинг на директориите.

Сега можем да отворим с Internet Explorer URL адреса на примера от публикуваната в IIS директория:

http://localhost/Demo-19-Custom-Controls-in-IE/index.html

Ще получим следния резултат:

Ако въведем час и минута и натиснем бутона, стрелките ще променят местоположението си.

Нишки и Windows Forms

Продължителните операции в Windows Forms приложенията трябва да се изпълняват в отделна нишка. В противен случай се получава "заспиване" на потребителския интерфейс. Как можем да използваме нишки, ще разгледаме подробно в темата "Многонишково програмиране и синхронизация", но засега можем да считаме, че нишките позволяват паралелно изпълнение на програмен код в нашите приложения.

Да вземем за пример операцията "изтегляне на файл от Интернет". Тя може да отнеме от няколко секунди до няколко часа и е недопустимо приложението да блокира, докато изтеглянето на файла не приключи. В такъв случай трябва да изпълним задачата в друга нишка (thread) и от време на време да показваме на потребителя индикация за напредъка, например чрез контролата ProgressBar. Има обаче един проблем, свързан с достъпа до потребителския интерфейс при работа с нишки.

Обновяването на потребителския интерфейс на дадена контрола трябва да става само от нишката, в която работи контролата. От друга нишка безопасно могат да се извикват само методите Invoke(), BeginInvoke(), EndInvoke() и CreateGraphics().

Никога не обновявайте Windows Forms контроли от нишка, която не ги притежава!

За изпълнение на методи от нишката, която притежава дадена контрола, използваме метода Invoke(…) на класа Control. Ето пример:

delegate void StringParamDelegate(string aValue);

class Form1 : System.Windows.Forms.Form

{

private void UpdateUI(string aValue)

{

// Update UI here …

// This code is called from the Form1's thread

}

void AsynchronousOperation()

{

// This runs in separate thread. Invoke UI update

this.Invoke(new StringParamDelegate(UpdateUI),

new object[]{"някакъв параметър"});

}

По този начин нишката, която извършва времеотнемащата работа, работи паралелно на нишката, която управлява потребителския интерфейс, но той се обновява само от неговата нишка-собственик. Ако обновяваме потребителския интерфейс от нишката, която извършва времеотнемащата операция, а не от главната нишка на приложението, се получават много странни ефекти – от "зависване" на приложението до неочаквани изключения и системни грешки. Не го правете!

Използване на нишки в Windows Forms приложения – пример

С настоящия пример ще илюстрираме използването на нишки (threads) в Windows Forms приложения за изпълнение на времеотнемащи задачи. Ще покажем правилния начин, по който една нишка, която се изпълнява паралелно с главната нишка на Windows Forms приложението, може да обновява неговия потребителски интерфейс.

Приложението, което ще създадем, ще търси прости числа (което е времеотнемаща операция) и ще ги показва на потребителя. Търсенето ще се извършва в отделна, паралелно изпълняваща се нишка, за да не "заспива" потребителският интерфейс.

Ето стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Asynchronos UI Update Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Добавяме във формата два бутона с имена ButtonStart и ButtonStop и един TextBox с име TextBoxLastPrimeNumber. На свойствата Text на бутоните задаваме съответно стойности Start и Stop. Задаваме стойност false на свойството Enabled на бутона ButtonStop.

4. Добавяме променлива за нишката, която търси прости числа:

private Thread mPrimeNumbersFinderThread = null;

5. Декларираме делегат, който ще използваме при извикването на метода Invoke(…), когато обновяваме потребителския интерфейс:

delegate void LongParameterDelegate(long aValue);

6. Дефинираме клас PrimeNumberFinder, чрез който ще търсим прости числа в интервала [0; 1 000 000 000]:

class PrimeNumbersFinder

{

private MainForm mMainForm;

public PrimeNumbersFinder(MainForm aMainForm)

{

mMainForm = aMainForm;

}

public void FindPrimeNumbers()

{

for (long number=0; number<1000000000; number++)

{

if (IsPrime(number))

{

mMainForm.Invoke(

new LongParameterDelegate(mMainForm.ShowPrimeNumber),

new object[]{number}

);

}

private bool IsPrime(long aNumber)

{

// Primarity testing. Very ineffective.

// Don't do it in a real case!!!

for (long i=2; i<aNumber; i++)

{

// Just waste some CPU time

int sum = 0;

for (int w=0; w<100000; w++)

{

sum += w;

}

if (aNumber % i == 0)

{

return false;

}

return true;

}

Понеже търсенето на прости числа ще се извършва в отделна нишка, в класа сме дефинирали променлива mMainForm, чрез която ще се обръщаме към главната форма, за да обновяваме потребителския интерфейс. Тази променлива се инициализира в конструктора на класа.

Методът IsPrime(…) проверява дали подаденото като параметър число е просто. Тази проверка нарочно се прави по изключително времеотнемащ, неефективен и натоварващ процесора начин, за да се симулира забавяне.

Методът FindPrimeNumbers() проверява последователно дали е просто всяко от числата в интервала от 0 до 1000000000. Ако числото е просто, през главната нишка на приложението се извиква методът ShowPrimeNumber(…), като му се подава като параметър намереното просто число. Този метод показва числото в потребителския интерфейс. Извикването се извършва чрез метода Invoke(…) на формата, който има грижата да изпълни подадения му делегат през нишката, в която работи формата.

Нишката, която търси прости числа, няма право да променя директно потребителския интерфейс на приложението, защото той работи в друга нишка. Ако две нишки работят с потребителския интерфейс едновременно, могат да възникнат непредвидими проблеми – блокиране на приложението, странни изключения или странни визуални ефекти.

7. Дефинираме в главната форма метода ShowPrimeNumber(…), който показва подаденото му като параметър число в текстовото поле TextBoxLastPrimeNumber:

internal void ShowPrimeNumber(long aNumber)

{

TextBoxLastPrimeNumber.Text = aNumber.ToString();

}

8. Добавяме обработчик на събитието Click на бутона ButtonStart. В него деактивираме Start бутона, активираме бутона Stop и стартираме отделна нишка, в която започваме да търсим прости числа:

private void ButtonStart_Click(object sender,System.EventArgs e)

{

ButtonStart.Enabled = false;

ButtonStop.Enabled = true;

PrimeNumbersFinder finder = new PrimeNumbersFinder(this);

mPrimeNumbersFinderThread =

new Thread(new ThreadStart(finder.FindPrimeNumbers));

mPrimeNumbersFinderThread.Start();

}

9. Добавяме обработчик на събитието Click на бутона ButtonStop. В него активираме Start бутона, деактивираме бутона Stop и прекратяваме изпълнението на стартираната нишка:

private void ButtonStop_Click(object sender, System.EventArgs e)

{

ButtonStart.Enabled = true;

ButtonStop.Enabled = false;

mPrimeNumbersFinderThread.Abort();

}

10. Добавяме обработчик на събитието Closing на главната форма. В него прекратяваме изпълнението на нишката, търсеща прости числа (в случай че е била стартирана):

private void MainForm_Closing(object sender,

System.ComponentModel.CancelEventArgs e)

{

if (mPrimeNumbersFinderThread != null)

{

mPrimeNumbersFinderThread.Abort();

}

11. Приложението е готово и можем да го стартираме и тестваме.

Въпреки че се извършва тежко изчисление и процесорът е натоварен на 100%, потребителският интерфейс не "замръзва". Ако все пак в даден момент се получи замръзване за кратко време, най-вероятно причината за това e включването на системата за почистване на паметта (Garbage Collector).

Влачене (Drag and Drop)

Реализацията на "влачене и пускане" (drag and drop) в Windows Forms приложение се извършва чрез обработването на поредица от събития.

В събитието MouseDown на контролата, от която започва влаченето, трябва да извикаме метода DoDragDrop(…), за да копираме данните, които ще влачим.

За да дадем възможност на контрола да получава данни при влачене, трябва да зададем стойност true на свойството й AllowDrop и трябва да прихванем събитията DragEnter и DragDrop. При обработка на DragEnter трябва да проверяваме формата на идващите данни и да позволяваме или забраняваме получаването им. Тази проверка можем да извършим чрез метода DragEventArgs.Data.GetDataPresent(…). В събитието DragDrop трябва да обработваме получените данни. Можем да ги извличаме посредством метода DragEventArgs.Data.GetData(…).

Влачене и пускане в Windows Forms – пример

Настоящия пример илюстрира как със средствата на Windows Forms могат да бъдат реализирани приложения, които използват Drag-and-Drop технологията (влачене и пускане на обекти от една контрола към друга).

Приложението, което ще създадем, ще съдържа две контроли – едната ще се използва като източник при влаченето, а другата като получател.

Ето и стъпките за изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Drag and Drop Demo". Променяме и името на файла с нейния сорс код от Form1.cs на MainForm.cs.

3. Добавяме във формата две ListBox контроли с имена ListBoxSource и ListBoxTarget. Те ще бъдат съответно източник и получател при влаченето.

4. Задаваме за свойството Items на ListBoxSource списък от имена на градове – София, Пловдив, Варна, …

5. Добавяме обработчик на събитието MouseDown на ListBoxSource. В него намираме избрания елемент от списъка и извикваме метода DoDragDrop(…), с което активираме влаченето. На метода подаваме като първи параметър данните, а като втори – стойност от изброения тип DragDropEffects, указваща какъв да е резултатът от влаченето – в нашия случай е копиране:

private void ListBoxSource_MouseDown(object sender,

System.Windows.Forms.MouseEventArgs e)

{

Point mouseLocation = new Point(e.X, e.Y);

int selectedIndex =

ListBoxSource.IndexFromPoint(mouseLocation);

if (selectedIndex != -1)

{

string data = (string) ListBoxSource.Items[selectedIndex];

ListBoxSource.DoDragDrop(data, DragDropEffects.Copy);

}

6. Задаваме на свойството AllowDrop на ListBoxTarget стойност true.

7. Добавяме обработчик на събитието DragEnter на ListBoxTarget. В него проверяваме дали влаченият обект е Unicode символен низ и съответно позволяваме или забраняваме пускането му:

private void ListBoxTarget_DragEnter(object sender,

System.Windows.Forms.DragEventArgs e)

{

if (e.Data.GetDataPresent(DataFormats.UnicodeText))

{

e.Effect = DragDropEffects.Copy;

}

8. Добавяме обработчик на събитието DragDrop на ListBoxTarget. В него извличаме низа и го обработваме:

private void ListBoxTarget_DragDrop(object sender,

System.Windows.Forms.DragEventArgs e)

{

string data =

(string) e.Data.GetData(DataFormats.UnicodeText);

ListBoxTarget.Items.Add(data);

}

9. Приложението е готово и можем да го стартираме и тестваме, като завлечем няколко града от списъка-източник в списъка-получател.

Конфигурационен файл на приложението

.NET Framework приложенията могат да използват конфигурационен файл, за да четат настройките си. Той представлява обикновен XML файл:

App.config

<?xml version="1.0" encoding="utf-8" ?>

</appSettings>

</configuration>

В тага <appSettings> могат да се добавят конфигурационни параметри на приложението, които представляват двойки от ключ и стойност. Настройките от конфигурационния файл могат да бъдат извличани по време на изпълнение по следния начин:

string username = System.Configuration.

ConfigurationSettings.AppSettings["username"];

// username = "Бай Иван"

От VS.NET можем да добавим конфигурационен файл като изберем File | Add New Item… | Application configuration file | App.config. При компилация App.config се копира под име <име_на_проекта.exe.config>.

Извличане на настройки от конфигурационен файл – пример

Настоящият пример илюстрира как можем да извличаме настройки от конфигурационния файл на приложението. Ще създадем приложение, което извлича стойност от своя конфигурационен файл и я показва.

Ето и стъпките на изграждане на нашето приложение:

1. Стартираме VS.NET и създаваме нов Windows Forms проект.

2. Задаваме на главната форма име MainForm и заглавие "Config File Demo". Променяме и името на файла от Form1.cs на MainForm.cs.

3. Добавяме във формата един TextBox с име TextBoxUserName и един бутон с име ButtonReadUserName. Задаваме на свойството Text на бутона стойност "Read user name from config file".

4. Добавяме конфигурационен файл на приложението, като избираме File | Add New Item… | Application configuration file | App.config. В него добавяме нов конфигурационен параметър с ключ username и стойност "Бай Иван":

App.config

<?xml version="1.0" encoding="utf-8" ?>

</appSettings>

</configuration>

5. Добавяме обработчик на събитието Click на ButtonReadUserName. В него извличаме стойността на параметъра username и я показваме в текстовото поле:

private void ButtonReadUserName_Click(object sender,

System.EventArgs e)

{

TextBoxUserName.Text = System.Configuration.

ConfigurationSettings.AppSettings["username"];

}

6. Приложението е готово и можем да го стартираме и тестваме:

Упражнения

1. Какво представлява библиотеката Windows Forms? Каква функционалност предоставя? Кога се използва?

2. Какво е компонент? Какво представлява компонентният модел .NET Framework? Какво е характерно за него?

3. Опишете програмния модел на Windows Forms. Каква функционалност реализира той?

4. Кои са най-важните класове от Windows Forms? Кои са най-важните им методи и свойства?

5. Какво е характерно за всички Windows Forms контроли? Кои са общите им методи и свойства?

6. Какво е характерно за формите в Windows Forms? Какви свойства и събития имат те?

7. Как се поставят контроли в дадена форма? Как се прихващат събития, породени от дадена контрола?

8. Реализирайте Windows Forms приложение, което представлява опростен вариант на стандартния калкулатор в Windows. Калкулаторът трябва да поддържа основните аритметични операции с цели и реални числа.

9. Със средствата на Windows Forms реализирайте играта "Хвани бягащия бутон". Играта представлява една форма, в която има един бутон със заглавие "Натисни ме". При приближаване на курсора на мишката в близост до бутона той трябва да "бяга от него" (да се премества на друго място във формата, възможно по-далече от курсора на мишката).

10. Със средствата на Windows Forms реализирайте проста информационна система за управление на клиентите на дадена фирма. Системата трябва да визуализира списък от клиенти (ListBox) и да позволява добавяне, редактиране и изтриване на клиенти. Всеки клиент е или юридическо или физическо лице. Юридическите лица се описват с наименование, вид (ЕТ, АД, ООД, сдружение, ...), Булстат, данъчен номер, адрес, телефон, email, уеб сайт и МОЛ (който е физическо лице). Физическите лица се описват с име, презиме, фамилия, пол, ЕГН, данни за лична карта, адрес, телефон и email. Приложението трябва да се състои от 3 форми – главна форма, съдържаща клиентите, форма за въвеждане/редакция на юридическо лице и форма за въвеждане/редакция на физическо лице. Използвайте подходящи Windows Forms контроли във формите. Данните трябва да се четат и записват в XML файл.

11. Със средствата на Windows Forms реализирайте специализиран редактор за библиотеки с текстови документи. Една библиотека представлява съвкупност от текстови документи, организирани дървовидно в папки. В една папка може да има документи и други папки (подобно на файловата система на Windows). Всеки документ представлява някакъв текст с форматиране. Редакторът трябва да може да създава библиотеки, да чете/записва библиотеки от/в XML файл. Когато е отворена дадена библиотека, редакторът трябва да позволява редактиране на документите в нея (промяна на текста и форматирането на отделни фрагменти от него), както и създаване/изтриване/преименуване на папки и документи. За дървото с папките трябва да се използва контролата TreeView, а за активния документ - RichEdit. Редакторът трябва да разполага с падащо меню, 2 контекстни менюта (за дървото с папките и за полето за редактиране на документ), 3 ленти с инструменти (за отваряне/записване на библиотека, за работа с дървото с папките и за форматиране на активния в момента документ), статус лента и подходящи кратки клавиши за по-важните команди. Реализирайте и търсене и заменяне на текст в документите.

12. Напишете Windows Forms приложение, в което се въвежда информация за физическо лице (име, презиме, фамилия, ЕГН, адрес, телефон, email, личен сайт) и въведеното се записва в XML файл. Реализирайте валидация на всяко едно от полетата и на цялата форма, като използвате подходящи регулярни изрази.

13. Със средствата на Windows Forms и простото свързване на данни (simple data binding) реализирайте приложение за управление на проста система с информация за градове и държави. Всяка държава се описва с име, език, население, национален флаг и списък от градове. Всеки град се описва с име, население и държава. Трябва да се реализира навигация по градовете и държавите и редакция на информацията за тях, като не се използват списъчни контроли, а само текстови полета и просто свързване. Да се реализира четене и записване на данните в XML файл.

14. Със средствата на Windows Forms и сложното свързване на данни (complex data binding) реализирайте система, подобна на системата за управление на информация за градове и държави. Добавете към системата списък от континенти за всяка държава. За визуализацията и навигацията използвайте таблици (DataGrid) и списъчни контроли. Реализирайте предходното приложение, като съхранявате данните не в XML файл, а в релационна база от данни (напр. MS SQL Server). Използвайте разкачения модел за достъп до данните (disconnected model), като реализирате възможност за разрешаване на конфликтите, които възникват при работа с много потребители едновременно.

15. Създайте Windows Forms приложение, с което могат да се въвеждат данни за физически и юридически лица. Физическите лица се описват с име, ЕГН, адрес, телефон, email и уеб сайт. Юридическите лица се описват с наименование, вид (ЕТ, АД, ООД, сдружение, ...), Булстат, данъчен номер, адрес, телефон, email, уеб сайт и МОЛ (име и ЕГН на физическо лице). Използвайте наследяване на форми, като отделите в базова форма общите елементи на потребителския интерфейс и общите полета от формите за въвеждане на физически и юридически лица.

16. Реализирайте Windows Forms приложение, което по ежедневните данни от дадено техническо измерване за даден период (текстов файл с цели положителни числа) визуализира графично резултатите като редица от правоъгълни стълбове. При обемни данни осигурете възможност за скролиране на графиката.

17. Със средствата на Windows Forms реализирайте играта "морски шах" (в квадратна дъска с размери 3 на 3 се поставят пулове "X" и "0"). Играчът трябва да може да играе срещу компютъра в 2 режима: "компютърът играе оптимално" и "компютърът играе хаотично (случайно)". Осигурете подходяща визуализация и интерактивност на играта.

18. Реализирайте Windows Forms MDI приложение, което може да отваря файлове с графични изображения (gif, jpg, png) и може да ги преоразмерява и да ги записва в друг файл.

19. Реализирайте Windows Forms приложение, което показва даден текстов файл, като визуализира всеки негов ред със специален ефект: всяка буква първоначално се появява на случайно място във формата и започва да се придвижва анимирано към мястото си. За 2 секунди всяка буква трябва да си е на мястото. След изчакване от 1 секунда се преминава към следващия ред от входния файл.

20. Със средствата на Windows Forms реализирайте прост текстов редактор, който може да отваря файлове с влачене от Windows Explorer.

21. Наследете контролата TextBox и създайте потребителска контрола NumberTextBox, която позволява въвеждане само на числа.

22. Направете Windows Forms потребителска контрола HourMinuteBox, която се състои от 2 NumericUpDown полета и позволява въвеждане на час и минута в интервала [0:00 - 23:59].

23. Реализирайте Windows Forms потребителска контрола "зарче", която представлява квадрат, в който могат да се изобразяват графично стойности от 1 до 6 (както са при стандартните зарчета при някои игри). Контролата трябва да реализира собствено изчертаване и свойство "Value" за задаване на текущата стойност.

24. С помощта на контролата "зарче" реализирайте играта "състезание": Двама играчи играят последователно. При всеки ход играчът, който е на ход, хвърля 2 зарчета (генерират се случайни стойности) и мести толкова стъпки, колкото е сумата от хвърлените зарове. Печели първият, който премине сумата 50. Реализирайте подходяща визуализация на позицията на двамата играчи на хвърлените зарове.

25. Реализирайте играта "състезание" като Windows Forms контрола и я хостнете в Internet Explorer, използвайки подходяща уеб страничка. Хвърлянето на заровете извиквайте с JavaScript при натискане на бутон от уеб страницата.

26. Със средствата на Windows Forms реализирайте приложение, което търси текст във всички файлове в дадена директория. Понеже търсенето е бавна операция, реализирайте я в отделна нишка. При намиране на текста добавяйте файла и отместването, на което е намерен, в ListBox контрола чрез главната нишка на приложението, като използвате Invoke() метода на формата. Реализирайте възможност за прекратяване на търсенето. Реализирайте подходяща визуализация при щракване върху някое от намерените съвпадения в резултата.

27. Реализирайте Windows Forms приложение, което съдържа една текстова контрола, стойността на която се зарежда от конфигурационния XML файл на приложението. При изход от приложението стойността на тази контрола трябва да се запазва обратно в конфигурационния файл. За четене от конфигурационния файл използвайте System. Configuration.ConfigurationSettings.AppSettings, а за писане в него използвайте DOM парсера на .NET Framework.

Използвана литература

1. Светлин Наков, Графичен потребителски интерфейс с Windows Forms – http://www.nakov.com/dotnet/lectures/Lecture-14-Windows-Forms-v1.0.ppt

2. MSDN Library - http://msdn.microsoft.com

3. Microsoft Windows Forms QuickStarts Tutorial –
http://www.csharpfriends.com/quickstart/winforms/doc/default.aspx

4. Marj Rempel, Kenneth S. Lind, Marjorie Rempel, MCAD/MCSD Visual C# .NET Certification All-in-One Exam Guide, McGraw-Hill, 2002, ISBN 0072224436

5. MSDN Library, Event Handling in Windows Forms – http://msdn.
microsoft.com/library/en-us/vbcon/html/vbconeventhandling.asp

6. Threading in Windows Forms –
http://www.yoda.arachsys.com/csharp/threads/winforms.shtml

7. J. Fosler, Windows Forms Painting: Best Practices –
http://www.martnet.com/~jfosler/articles/WindowsFormsPainting.htm

Глава 16. Изграждане на уеб приложения с ASP.NET

Автори

Михаил Стойнов

Рослан Борисов

Стефан Добрев

Деян Варчев

Иван Митев

Христо Дешев

Необходими знания

- Базови познания за езика C#

- Базови познания за архитектурата на .NET Framework

- Базови познания по Интернет технологии

- HTTP (Hyper Text Transfer Protocol)

- HTML (Hyper Text Markup Language)

- Познания за архитектурата на уеб базираните приложения

Съдържание

- Въведение

- Уеб форми

- Контроли

- Изпълним код на уеб форми и контроли (code-behind)

- Събития

- Проследяване и дебъгване

- Валидация на данни

- Работа с бази от данни

- Управление на състоянието

- Оптимизация, конфигурация и разгръщане

- Сигурност

В тази тема ...

В настоящата тема ще разгледаме разработката на уеб приложения с ASP.NET. В началото ще запознаем читателя с уеб формите и техните основни директиви, атрибути и тагове. Ще разгледаме видовете уеб контроли, които се използват при изграждане на уеб приложения, и по-важните от тях. Ще разгледаме концепцията за отделяне на кода от потребителския интерфейс (code-behind), ще обясним програмния модел на ASP.NET и работата със събития. След това ще демонстрираме как да работим с данни, извлечени от релационна база от данни. Ще обърнем специално внимание на принципите на свързване на контроли с данни (data binding) и ще обясним как да свързваме списъчни и итериращи контроли. Ще разгледаме как можем да управляваме вътрешното състояние на уеб приложението: работа със сесии и cookies, достъп до контекста на приложението и технологията ViewState. Ще покажем как да валидираме данни, въведени от потребителя, чрез различните валидатори. Ще обясним концепцията за потребителските контроли като метод за преизползване на части от приложението. Ще се научим как да проследяваме и дебъгваме уеб приложения. Ще покажем как се оптимизират, конфигурират и разгръщат ASP.NET уеб приложения (кеширане, настройки и deployment). Ще обърнем специално внимание и на сигурността при уеб приложенията.

Въведение

ASP.NET е библиотека за разработка на уеб приложения и уеб услуги, стандартна част от .NET Framework. Тя дава програмен модел и съвкупност от технологии, чрез които можем да изграждаме сложни уеб приложения.

Изпълнение на ASP.NET уеб приложение

Уеб приложенията използват модела заявка-отговор (request-response), както е показано на фигурата:

1. Потребителят въвежда в браузъра адрес на страница (URL). Браузърът изпраща HTTP заявка (request) към уеб сървъра.

2. Сървърът получава заявката и я обработва. В случая с ASP.NET, IIS намира процес, който може да обработи дадената заявка.

3. Резултатът от вече обработената заявка се изпраща обратно към потребителя/клиента под формата на HTTP отговор (response).

4. Браузърът показва получения отговор като уеб страница.

Преглед на технологията ASP.NET

ASP.NET е програмна платформа за разработка на уеб приложения, предоставена от .NET Framework. Тя предлага съвкупност от класове, които работят съвместно, за да обслужват HTTP заявки. Също като класическите ASP (Active Server Pages), ASP.NET се изпълнява на уеб сървър и предоставя възможност за разработка на интерактивни, динамични, персонализирани уеб сайтове, както и на уеб базирани приложения. АSP.NET е също и платформа за разработка и използване на уеб услуги.

ASP.NET и .NET Framewrok

На фигурата са показани основните компоненти на .NET Framework, част от които е библиотеката ASP.NET.

Разлики между ASP и ASP.NET

Разликите между ASP и АSP.NET са значителни. АSP.NET предлага ново ниво на абстракция за разработка на уеб приложения. Ключова характеристика на ASP.NET е възможността за разделяне на кода описващ дизайна от кода, реализиращ логиката на приложенията. ASP.NET приложенията могат да бъдат разработвани с помощта на всички езици за програмиране, които се компилират до MSIL код (C#, VB.NET, J#, Managed C++ и много други).

Фундаменти на ASP.NET

Основният компонент на ASP.NET е уеб формата – абстракция на HTML страницата, която интернет потребителите виждат в браузъра си. Замисълът на създателите на ASP.NET е работата с уеб формите да бъде интуитивна и максимално улеснена, както е при Windows Forms формите. ASP.NET предлага едно високо ниво на абстракция, предоставяйки ни богат избор от уеб контроли, подобни на тези в Windows Forms, и намалява нуждата програмиста да работи с чист HTML код.

Всяко ASP.NET приложение се изгражда от една или повече уеб форми, които могат да взаимодействат помежду си, създавайки интерактивна система.

Как работи ASP.NET?

Традиционните уеб страници могат да изпълняват код на клиента, с който извършват сравнително прости операции.

ASP.NET уеб формите могат да изпълняват и код от страна на сървъра (server-side code). С него те генерират HTML код, който да се върне като отговор на заявката. За целта могат да се извършват обработки, изискващи достъп до бази от данни и до ресурсите на самия сървър, генериращи допълнителни уеб форми и други.

Всяка уеб форма в крайна сметка се трансформира в HTML код, пригоден за типа на клиентския браузър. Това позволява улеснена разработка на уеб форми. Те работят практически върху всяко устройство, което разполага с интернет свързаност и уеб браузър.

Разделяне на визуализация от бизнес логика

Един от основните проблеми на класическите ASP беше смесването на HTML с бизнес логика. Това правеше страницата трудна за разбиране, поддръжка и дебъгване. Файловете ставаха големи и сложни и се забавяше процеса на разработка на приложението. Една от основните архитектурни цели на АSP.NET e справянето с този проблем. Тъй като реализацията на потребителския интерфейс и на бизнес логика са до голяма степен, две независими задачи, ASP.NET предоставя модел за разработка, при който те са физически разделени в отделни файлове.

Програмирането за клиентския интерфейс (UI) се разделя на две части:

- За визуализация се използва HTML-подобен код, записан във файл с разширение .aspx.

- Бизнес логиката се дефинира в отделен файл (с разширение .cs за C# или .vb за Visual Basic .NET), съдържащ конкретната имплементация на определен програмен език.

Файлът, съдържащ бизнес логиката, се нарича "Изпълним код на уеб формата" (Code-behind).

Зад всяка уеб форма стои богатият обектен модел на .NET Framework и тя се компилира до клас в асемблито на проекта ни.

Класът, генериран от .aspx файл, се непряк наследник на Page класа. Съществува междинен клас в йерархията, който е за изпълнимия код (code-behind class). В него можем лесно да добавяме методи, обработка на събития и др.

Чрез "изпълнимия код" представянето е разделено от логиката. Това улеснява значително поддръжката на .aspx страниците.

Компоненти на ASP.NET

Ето кои са основните компоненти, от които се изграждат уеб приложенията, базирани на ASP.NET:

Web Forms – описват интерфейса за ASP.NET приложение.

Code-behind класове – асоциират се с уеб форми и контроли и съдържат server-side код.

Web.config – файл, съдържащ конфигурацията на ASP.NET приложението.

Machine.config – файл с глобални настройки за уеб сървъра.

Global.asax – файл, съдържащ код за прихващане на събития на ниво приложение (application level events).

Съществуват и други компоненти като Http Modules, Http Handlers и други, но на тях няма да се спираме.

Пример за уеб приложение

Ще създадем примерно уеб приложение чрез Visual Studio.NET, за да разгледаме структурата на директориите и файловете му. Отваряме Visual Studio.NET и създаваме нов уеб проект с име Demo-1-ExampleOfWebApplication:

Отляво е кутията с инструменти (toolbox), където са контролите. Нека добавим текстово поле и бутон, като привлачим двете контроли върху формата.

Можем да разгледаме кода на страницата (code-behind класа) като върху формата натиснем [F7].

Можем да компилираме и стартираме приложението с [Ctrl+F5].

ASP.NET Web Application проекти във VS.NET

При създаване на проект за .NET уеб приложение (ASP.NET Web Application) във Visual Studio .NET, се създават две директории.

В едната (по подразбиране това е \My Documents\Visual Studio Projects) се намира solution файла (.sln). Той описва проектите, участващи в приложението. Обикновено в поддиректории се съхраняват останалите проекти от solution файла.

Втората директория е с идентично име и се създава в уеб-достъпна папка, като най-често това е папката c:\inetpub\wwwroot. Тя съдържа файловете, които са нужни на уеб приложението: .aspx страниците, техните code-behind файлове и файловете Web.config и Global.asax. Когато се компилира проекта, се създава съответно асембли в директорията bin.

Забележка: Директорията c:\inetpub\wwwroot е коренната (root) виртуална директория по подразбиране на уеб сървъра Internet Information Server (IIS), с който по подразбиране работи Visual Studio.NET за разгръщане на приложенията си.

Виртуална директория е такава, която се вижда през протокола HTTP, например:

Ако отваряме сървъра локално, можем да го извикаме с адреса http://localhost/.

Като направим директорията c:\inetpub\wwwroot\Lecture-15-ASP.NET-and-Web-Applications\Demo-1-ExampleOfWebApplication, тя ще се вижда през протокола HTTP като виртуалната директория:

http://localhost/Lecture-15-ASP.NET-and-Web-Applications/Demo-1-ExampleOfWebApplication/.

Модел на изпълнение на ASP.NET

Моделът на изпълнение (execution model) на ASP.NET е следният:

1. Клиентският браузър изпраща HTTP GET заявка на сървъра.

2. Сървърът намира за коя страница е заявката и започва да я изпълнява.

3. ASP.NET парсерът интерпретира нейния сорс код.

4. Ако кодът не е бил компилиран в асембли, ASP.NET извиква компилатора.

5. Средата за изпълнение (CLR) зарежда в паметта и изпълнява Microsoft Intermediate Language (MSIL) кода.

6. Страницата се изпълнява и генерира HTML код. Сървърът връща този резултат на клиента като HTTP отговор.

Уеб форми

ASP.NET уеб приложенията представляват най-общо съвкупност от уеб форми. Нека разгледаме как можем да създаваме и използваме уеб форми.

Какво е уеб форма (Web Form)?

Уеб формата е програмируема уеб страница. Тя служи като потребителски интерфейс в ASP.NET уеб приложенията. Уеб формите съдържат HTML код и контроли. Те се изпълняват на уеб сървъра. Най-често това е Microsoft Internet Information Server (IIS). Уеб формите връщат като резултат потребителски интерфейс, под формата на HTML код, който се изпраща на клиентския браузър.

Създаване на уеб форма

Функциите на уеб формата се дефинират, като се използват три нива на атрибути.

Атрибутите на @Page директивата дефинират глобална функционалност. Атрибутите на body тага дефинират как ще се покаже една страница. Атрибутите на form тага дефинират как ще се обработят групите контроли.

Top of Form

Bottom of Form

дфдсфдсфTop of Form

Bottom of Form

сдфдфсфдссдфTop of Form

Bottom of Form

<%@ Page Language="c#"

Codebehind="WebForm1.aspx.cs"

Inherits="WebApplication1.WebForm1"%>

<html>

<head><title>WebForm1</title></head>

<asp:Button ...></aspButton>

</form>

</body>

</html>

Забележка: @Page директивата е специална конструкция, използвана в ASP.NET уеб формите. Въпреки че и в HTML има <body> и <form> тагове, същите (когато са записани така <body runat="server" ...> и <form runat="server" ...>) играят по-специална роля в ASP.NET. Тези особености са обяснени в детайли по-нататък.

Поддържат се два вида разполагане на HTML елементите на страницата.

- FlowLayout: HTML обектите се нагласят по ширината на прозореца на браузъра.

- GridLayout: HTML обектите са с абсолютни координати на HTML страницата. Това е стойността по подразбиране.

Директиви

Директивите предоставят възможност за контролиране на компилацията и изпълнението на уеб формата. Името на всяка директива започва с "@" и е заградено с <% и %> тагове. Директивите могат да бъдат поставени навсякъде в .aspx файла на формата, но обикновено се поставят в началото му. Настройките и опциите към всяка директива се задават като атрибути.

Важни директиви:

- @Page – главна директива за формата (по-късно разгледана);

- @Import – въвежда дадено пространство от имена във формата;

- @Implements – указва, че формата (или контролата) имплементира даден интерфейс;

- @Control – аналог на @Page директивата (използва се само за потребителски контроли);

- @OutputCache – контролира способността за кеширане на формите;

- @Register – регистрира контрола за употреба в уеб форма;

- @Reference – декларативно указва, че сорс файлът на друга потребителска контрола или форма трябва да бъде динамично компилиран и свързан с формата, в която е декларирана директивата.

Ето един пример за използване на @Page директивата:

<%@ Page Language="c#" Codebehind="WebForm1.aspx.cs" Inherits="WebApplication1.WebForm1"%>

Директивата <@Page …>

Дефинира специфични за формата (.aspx файл) атрибути, използвани от парсера и компилатора на ASP.NET.

Важни атрибути:

- AutoEventWireup – решава автоматичното абониране за събитията на страницата и контролите.

- Culture – определя културата (регионалните настройки), която да се използва при обработка на данните.

- UICulture – определя културата за видимите от потребителя текстови съобщения.

- Debug – определя дали тази страница е компилирана с дебъг символи (debug symbols).

- EnableSessionState – определя дали ще се поддържа сесията.

- EnableViewState – определя дали ще се използва "view state".

- ErrorPage – определя страница, към която ще се пренасочва в случай на необработено изключение.

Атрибути на директивата <@Page …>

Чрез използването на @Page атрибути се дефинират глобални свойства на уеб формата. Тагът <@ Page> дефинира специфични за страницата атрибути. Те се използват от парсера за страници на ASP.NET и компилатора. В даден .aspx файл може да бъде включи само един <@ Page> таг.

Атрибутът Language дефинира програмния език на скрипта в уеб страницата. Най-често използвани са: Visual Basic.NET и C#, като се поддържат и Visual J#, JScript.NET и т.н.

Атрибутът CodeBehind сочи към code-behind страницата (файла), който съдържа логиката на уеб формата. При създавана на уеб форма във Visual Studio.NET (например WebForm1.aspx), се създава автоматично и code-behind клас във файл с име: WebForm1.aspx.vb или WebForm1.aspx.cs.

Атрибутът SmartNavigation в ASP.NET инструктира браузъра да опреснява само тези секции от формата, които са се променили. Технологията Smart Navigation премахва премигването на екрана при опресняване. Scroll позицията се запазва и "last page" в историята остава същата. Smart Navigation е достъпен само за ползватели на Microsoft Internet Explorer 5 или по-нов.

Тагът <form>

Тагът <form> дефинира как ще бъдат обработени контролите. Той е различен от едноименния таг в езика HTML – тук дефинира контейнер на контроли за цялата уеб страница. На една уеб форма може да има много <form> HTML елементи, но само един от тях може да е сървърна контрола в .aspx страницата.

HTML страница

ASP.NET страница (само една форма)

Вградени обекти в ASP.NET

Всяка страница в ASP.NET приложението е наследник на класа Page, който предлага множество полезни свойства. Сега ще изброим по-важните, а по-късно ще разгледаме в детайли начина на употреба на повечето от тях:

- Application (клас HttpApplication) – приложение;

- Session (клас HttpSession) – сесия;

- Request (клас HttpRequest) – заявка;

- Response (клас HttpResponse) – отговор;

- Server (клас HttpServerUtility) – сървър;

- Context (клас HttpContex) – контекст;

- Cache (клас System.Web.Caching.Cache) – кеш.

Ако искаме да препратим изпълнението към друга страница, можем да използваме два метода: чрез свойствата Response и Server.

- Response.Redirect("Login.aspx") – пренасочване от страна на клиента (client redirection). Променя адреса на уеб браузъра.

- Server.Forward("WebForm1.aspx") – пренасочване от страна на сървъра (server redirection). Запазва адреса на уеб браузъра. На практика Web браузърът не разбира за пренасочването.

Уеб контроли

Уеб контролите представляват компоненти, от които се изграждат ASP.NET уеб формите. Те се изпълняват на сървъра по време на зареждане на уеб формата и се "рендират" (трансформират) до HTML контроли, които след това се визуализират от клиентския уеб браузър.

ASP.NET сървърни контроли

ASP.NET сървърната контрола (ASP.NET server control) е компонент, който се изпълнява на сървъра и обвива потребителски интерфейс и друга функционалност. Сървърните контроли се използват в ASP.NET страниците и code-behind класовете. Сред тях има контроли за бутони, текстови полета (text boxes), падащи (drop-down) списъци и други.

Всички server контроли имат атрибутите id и text, както и runat="server" атрибута. Последният атрибут означава, че логиката (кода) на контролата се изпълнява на сървъра, а не при клиента, както е с HTML елементите.

Сървърните контроли ни дават възможност за обработка на събития в код, изпълняван на сървъра. Обработчик на събитие е процедура, която се изпълнява в резултат потребителско действие (щракане на бутон, списък и др). Кодът, който се изпълнява, се слага в така наречените събитийни (event) процедури. Вие като програмист на уеб форми решавате как да обработвате събитията на съответната контрола.

Общ модел на ASP.NET сървърните контроли

В ASP.NET сървърните контролите са базирани на общ модел и като резултат споделят голям брой атрибути.

Например, когато трябва да се смени цветът на фона на контрола, винаги се използва едно и също свойството BackColor. Следният HTML код, който описва server контрола, показва някои типични атрибути:

<asp:Button id="Button2" runat="server" BackColor="red" Width="238px" Height="25px" Text="Web control"></asp:Button>

Специфичен за различните браузъри HTML код

Когато една страница се подготвя за клиента (rendering), сървърната контрола доставя HTML код, съобразен с вида на браузъра, подал заявката.

Например, ако браузърът поддържа възможност за четене на скрипт (client-side scripting), какъвто е Internet Explorer version 4.0 или по-нова, контролите създават такъв клиентски скрипт (client-side script), за да си имплементират част от функционалността директно на клиентския браузър. Ако не поддържа клиентски скрипт, контролите създават код, изпълняван на сървъра (server-side код), който имплементира същата функционалност, но за да се получи същата функционалност се правят повече заявки до сървъра.

Следният код е отрязък от ASP.NET уеб форма, която ще създаде текстово поле с текст "Enter your Username":

<asp:TextBox id="Textbox2" runat="server" Width="238px" Height="25px">Enter your Username</asp:TextBox>

Когато тази страница се достъпва от потребител с Internet Explorer 6, средата за управление (CLR) създава следния HTML код:

Server контролите могат да генерират различен HTML код за отделните браузъри. Примерно контролът Panel, води до генериране на <div> в Internet Explorer 6, а на другите браузъри <table>. За разработчиците това става прозрачно и ни позволява да се концентрираме върху логиката на приложението.

HTML сървърни контроли (HTML server controls)

HTML сървърните контроли наподобяват традиционните HTML елементи.

HTML елементите се третират от уеб формата като обикновен текст и техните атрибути не са достъпни за сървъра. С конвертирането на HTML елементи към HTML server контроли е възможен достъпа до техните атрибути от server-side код. Това конвертиране позволява контролите да инициират събития, които се обработват на сървъра.

HTML server контролите имитират HTML елементите синтактично, с разликата, че включват атрибута runat="server". За тях има изискване да са вложени в контейнер <form "runat="server">...</form>. Намират се в пространството от имена System.Web.UI.HtmlControls.

HTML сървърни контроли – пример

Ще направим уеб приложение, в което ще има проста HTML страница. След това стъпка по стъпка от нея ще създадем уеб форма с HTML контроли в нея. За база ще използваме HTML таговете от първоначалната страница. Нека имаме следния код в HTML страницата:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >

<html>

<head>

</head>

<body>

Username: <br />

Password: <br />

</form>

</body>

</html>

Това е обикновена HTML форма за потребителско име и парола.

Първото изискване, за да направим тази HTML страница уеб форма, е да добавим runat="server" в HTML таговете за въвеждане на данни (<input type="text" …>), както и на обграждащата ги HTML форма (<form …>).

Това е достатъчно, за да компилираме страницата като ASP.NET форма.

Ако искаме да добавяме код директно в страницата, а не в code-behind клас трябва да добавим директивата <%@Page ... %> като минимум укажем програмния език, който ще използваме (C#, Visual Basic.NET, Jscript.NET …).

Ако искаме да достъпваме контролите (<input type="text" runat="server" …>) от code-behind класа, трябва да им добавим и име, с което да бъдат достъпвани id="UsernameTextbox". Променлива със същото име трябва да бъде налична и в code-behind страницата.

След всички тези промени ето как изглежда нашата нова ASP.NET страница:

<%@ Page language="C#" AutoEventWireup="false" %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >

<html>

<head>

</head>

<body>

Username: <br/>

Password: <br />

</form>

</body>

</html>

Когато компилираме и стартираме новата ни уеб форма, тя изглежда и работи така, както очакваме:

Кодът на HTML страницата не се е променил, докато ето какво получаваме като отворим сорс кода на уеб формата в браузъра (View à Source в Internet Explorer):

Кодът на уеб формата е близък до този на HTML страницата, когато формата е компилирана.

Уеб сървърни контроли (Web server controls)

Web server контролите са сървърни контроли, създадени специално за ASP.NET. Те включват не само form-type контроли като бутони и текстови кутии, но също контроли със специално предназначение като календар контролата (виж фигурата по-долу). Web server контролите са по-абстрактни от HTML server контролите. Техният обектен модел не е задължително да наподобява синтаксиса на HTML.

Характеристики на уеб сървърните контроли

Web server контролите се базират на общ модел и всички споделят общи характеристики: тага <asp:ControlType...> и атрибута id. Web server контролите няма да функционират без атрибута runat="server". Web server контролите се намират в пространството от имена System.Web. UI.WebControls и могат да се използват във всяка уеб форма.

<asp:Button id="MyBtn" runat="server">

<asp:Calendar id="MyCal" runat="server">

<asp:TextBox id="MyTxt" runat="server">

Кои контроли да ползваме?

Когато се създават ASP.NET страници, има възможност да се използват HTML server контроли или Web server контроли. Могат да се смесват безпрепятствено. Например - за бързо преправяне на HTML страница в ASP.NET страница.

Използването на Web server контролите е препоръчително пред HTML server контролите, тъй като те имат повече възможности и по-богат обектен модел.

Използвайте HTML сървърни контроли, ако:

- Предпочитате HTML-подобен обектен модел. HTML server контролите имат почти същия синтаксис като HTML елементите. HTML server контролите имат server-side функционалност също като Web server контролите.

- Работите със съществуващи HTML страници и искате бързо да им добавите функционалността на уеб формите. Заради това, че HTML server контролите съответстват точно на HTML елементите, не е нужно да подменяте контроли и да рискувате да се появят грешки при форматирането на страницата заради подмяната.

- Контролите трябва да изпълняват едновременно client-side и server-side скрипт. Можете да пишете client-side скрипт и да посочвате контролите с HTML името им (<tag name="html_name">), защото при клиента те са HTML елементи. В същото време можете да пишете server-side код, защото те са server контроли.

- Скоростта на връзката (bandwidth) е ограничена и трябва да обработвате голяма част от данните при клиента, за да намалите натовареността.

Използвайте Web server контроли, ако:

- Предпочитате компонентния модел на .NET. Ще имате възможността да използвате обектно-ориентирано програмиране, ще можете да идентифицирате контролите по техния id атрибут и лесно да разделяте логиката от потребителския интерфейс. С Web server контролите ще можете да създавате приложения с вложени контроли и да управлявате събитията (events) на ниво контейнер на контроли (container level events).

- Създавате уеб страници, които ще бъдат разглеждани на различни браузъри. Контролите има способността да генерират HTML, който е съобразен с възможностите на клиентския браузър и се възползва от всички негови предимства. Така можете да пишете за последните версии на браузърите, без да се притеснявате, че по-старите версии няма да могат да работят с пълната функционалност на страницата ви.

- Имате нужда от специфична функционалност като например календар или банери, която е имплементирана само в Web server контроли. В Интернет има огромно разнообразие от Web server контроли, които решават специфичен проблем.

- Скоростта на връзката (bandwidth) ви не е твърде ограничена и увеличен брой връщания до сървъра (цикли от заявка-отговор) от клиента няма да създадат проблеми със скоростта.

Категории уеб сървърни контроли

Web сървър контролите се делят на:

- Вътрешните контроли (Intrinsic controls) съответстват на прости HTML елементи като бутони или списъци. Използват се по същия начин като HTML server контролите.

- Контролите за валидация (Validation controls) включват логика, която позволява валидация на потребителски въведени данни по унифициран начин. Контролата за валидация трябва да се прикрепи към контрола, приемаща потребителски вход и да се опишат правилата за валиден вход.

- Обогатените контроли (Rich controls) включват по-сложни функции. Пример е AdRotator контролата, която се използва за показване на последователност от картинки (използва се за банери) или Calendar контролата, която представлява календар.

- List-bound контролите могат динамично да показват данни на ASP.NET уеб страница. Дават възможността за показване, форматиране на изхода, сортиране и промяна.

- Internet Explorer уеб контролите са група сложни контроли, например MultiPage, TabStrip, Toolbar, and TreeView контролите, които могат да бъдат свалени от Интернет и да се интегрират във Visual Studio .NET за използване във всяко ASP.NET уеб приложение. Тези контроли могат да бъдат изобразени като стандартен HTML, но могат да се възползват и от допълнителните възможности на Internet Explorer 5.5 или следващи версии, при което имат по-богата функционалност.

Вътрешни контроли и съответствие с HTML

Вътрешните (intrinsic) Web server контроли отговарят на прости HTML елементи. Някои от често използваните вътрешни Web server контроли са показани в таблицата:

Вътрешни уеб контроли	HTML тагове
<asp:button>	<input type="submit">
<asp:checkbox>	<input type="checkbox">
<asp:hyperlink>	<a href="..."></a>
<asp:image>	<img src="...">
<asp:imagebutton>	<input type="image">
<asp:linkButton>
<asp:label>	<span> </span>
<asp:listbox>	<select size="5"></select>
<asp:panel>	<div> </div>
<asp:radiobutton>	<input type="radio">
<asp:table>	<table> </table>
<asp:textbox>	<input type="text">

Контроли за валидация

Контролите за валидация са скрити контроли, които проверяват данните, въведени от потребителя, срещу предефинирани правила. Ще изброим набързо някои от често използваните контроли за валидация

- RequiredFieldValidator – изисква входът да е стойност, различна от празната (т.е. да се въведени някакви данни).

- CompareValidator – проверява дали стойността на контролата е равна, по-голяма или по-малка от друга.

- RangeValidator – изисква входът да е в някакви граници (обхват).

- RegularExpressionValidator – изисква входът да отговаря на предефиниран регулярен израз (например пощенски код, телефонен номер …).

- CustomValidator – позволява задаването на произволно условие, което може да се дефинира и изпълни и на клиента и на сървъра (например условие за просто число).

- ValidationSummary – събирателна контрола, която може да извежда съобщенията за грешка на всички контроли за валидация.

Обогатените контроли (Rich controls)

Обогатените контроли (Rich controls) са специфични контроли, които решават сложна, но често срещана задача. Техни представители са:

- AdRotator – показва последователност (предефинирана или случайно генерирана) от изображения. Най-често се използва за банери.

- Calendar – показва графично представяне на интерактивен календар.

Списъчни контроли (List-bound controls)

List-bound контролите могат да показват данни от източник (най-често бази от данни). Някои от най-често използваните са описани по-долу:

- CheckBoxList – показва данните като колона от check boxes.

- DropDownList – показва данни като падащ списък.

- Listbox – показва списък от елементи в кутийка.

- RadioButtonList – показва данните като колона от бутони за алтернативен избор (radio buttons).

- Repeater – показва информация (от DataSet или масив), като повтаря потребителски дефиниран шаблон. Шаблонът описва как се представя всеки един елемент. В този шаблон най-често има други контроли.

- DataList – подобна на контролата Repeater, но с повече форматиращи и layout опции, включително и възможността данните да се показват в таблица. DataList контролата също позволява да се определи и поведение при редактиране на данните.

- DataGrid – показва данните в табличен вид. Доставя механизми за редактиране, сортиране и страниране.

Code-behind

Отделянето на програмния (C#) код, свързан с презентационната логика на приложението, от потребителския му интерфейс значително улеснява поддръжката на уеб приложенията.

В ASP.NET кодът на aspx страниците обикновено се отделя от програмния (C#) код, който ги управлява. Този програмен код се грижи за подготовката на страницата за визуализация и за взаимодействието с потребителя и е известен още като "презентационна логика". В него се обработват събитията, предизвикани от контролите в уеб формата.

За отделянето на презентационната логика от потребителския интерфейс обикновено с всяка aspx страница е свързан един C# клас – файл с разширение aspx.cs. Този файл е известен като "code behind" и се поддържа автоматично от VS.NET.

Добавяне на код в уеб форма

Добавянето на код в ASP.NET уеб форма ви дава възможност да предоставите функционалността, от която потребителят се нуждае. Без код вашето уеб приложение може да изглежда добре, но няма да прави нищо.

Добавянето на код в уеб форма става по един от три начина:

- Mixed code – кодът е в същия файл, в който е и уеб съдържанието. Този метод не се препоръчва, защото води до сложен и труден за поддържане код. Използвал се е при ASP приложенията. Такъв метод видяхме в някои от примерите от последната демонстрация.

- Inline code – кодът е отделен в отделна SCRIPT секция в същия файл.

- Code-behind – кодът е в code-behind страница – отделен файл от този на HTML съдържанието. Когато използвате Visual Studio.NET, това е методът по подразбиране.

Inline code

Когато се използва inline код, HTML кодът и inline кодът са в отделни секции на един и същ .aspx файл. Това разделение е за яснота, когато се чете страницата. Двете секции могат да се намират навсякъде по страницата.

<html>

<asp:Button id="btn" runat="server"/>

...

</html>

private void btn_Click(object sender, System.EventArgs e)

{

...

}

</script>

Code-behind класове

Code-behind класовете представляват отделни компилирани класове, който съдържат програмната логика на страницата. Всяка уеб страница в едно уеб приложение има собствена code-behind страница. По подразбиране code-behind страницата има същото име като уеб страницата, с която е асоциирана. Разширението на файла е .aspx.vb или .aspx.cs в зависимост от това какъв език е бил използван. Когато уеб приложението се изпълнява двата файла формират цялата страница.

Как работи code-behind?

За да асоциира една .aspx страница с нейната code-behind страница, Visual Studio .NET добавя три атрибута към @Page директивата:

- Inherits – позволява на .aspx страницата да наследява code-behind класа.

- Codebehind – използва се вътрешно от Visual Studio .NET, за да асоциира файловете.

- Src – съдържа името на code-behind страницата. Използва се, ако уеб приложението не е прекомпилирано.

<%@ Page Language="c#"

Inherits="MyProject.WebForm1"

Codebehind="WebForm1.aspx.cs"

Src="WebForm1.aspx.cs" %>

JIT компилация

Code-behind страницата може или да бъде прекомпилирана от Visual Studio .NET, когато се компилира уеб приложение, или да бъде just-in-time (JIT) компилирана при първата заявка.

Ако Src атрибутът липсва от <@Page ...> директивата в .aspx файла, при build на приложението страницата се компилира. По подразбиране Visual Studio .NET не добавя атрибута Src, т.е. всички code-behind страници са компилирани, когато се стартира приложението. Прекомпилирането спестява забавянето при първа заявка за съответната страница. Друго предимство е, че няма нужда сорс кодът на code-behind страниците да се разпространява до уеб сървъра.

Когато се използва JIT компилация, code-behind страницата се компилира при първа заявка. Съответно първата заявка е по-бавна.

Събития

Когато потребител взаимодейства с уеб форма (щрака, избира, въвежда данни), се генерира събитие (event). Действието, което трябва да се извършва в отговор, се реализира в събитийна (event) процедура.

Прихващане на събития

Нека създадем контрола, за да генерираме събитие в уеб формата. Visual Studio .NET декларира променлива в code-behind страницата с име като id атрибута на контролата.

Следният HTML код дефинира уеб форма и бутон с id="Button1":

<asp:Button id="Button1" runat="server"/>

</form>

В code-behind страницата се декларира променлива със същото име:

protected System.Web.UI.WebControls.Button Button1;

Когато щракнем с мишката два пъти върху този бутон, VS.NET прихваща събитието "натискане на бутона" и генерира метод, който се извиква при неговото настъпване. Ето как изглежда генерираният метод:

private void Cmd1_Click(object sender, System.EventArgs e)

{

// Event handling goes here ...

}

Самото абониране за събитието на бутона става по начина, по който става в Windows Forms. VS.NET добавя следния код в инициализационната част на страницата:

this.Button1.Click +=

new System.EventHandler(this.Button1_Click);

Свойството AutoEventWireup

Свойството AutoEventWireup указва дали събитията автоматично да се връзват към страницата.

Ако е true, следният код е излишен (изпълнява се автоматично):

this.Init += new System.EventHandler(this.Page_Init);

this.Load += new System.EventHandler(this.Page_Load);

ASP.NET сам намира методи с имена като Button1_Click и ги извиква като обработчик на събитието Click за контрол Button1.

При нужда от висока производителност, се препоръчва да не се използва автоматично връзване.

Жизнен цикъл на ASP.NET страниците

При всяка заявка за ASP.NET страница серия от събития се случват в строго определена последователност, известна като "жизнен цикъл на страницата" (page event life cycle). Тук ще изброим и обясним някои от по-важните събития:

Page_Init – служи за инициализиране на Web server контролите в страницата. По време на изпълнението му не трябва да се осъществява достъп до контролите. Може да се използва за заделяне на ресурси.

Page_Load – извиква се всеки път, когато страницата бъде поискана - както при първоначално отваряне на страницата, така и след потребителско действие (примерно натискане на бутон в нея). Събитието се използва за извличане на данните, попълнени в контролите, както и за промяна на състоянието на контролите в страницата.

Събитията на контролите служат за обработки в code-behind частта, които са свързани с отделните контроли от страницата (например Button1_Click, TextBox1_Changed).

Page_PreRender – извиква се преди да се започне рендирането (rendering) на страницата. Рендирането на страницата е процесът на създаване на изходния HTML код от .aspx страницата, включващ контролите в нея и данните, получени от потребителя до момента. На тази стъпка стойностите на контролите са възстановени от визуалното състояние (view state) и могат да бъдат нанесени последни промени, които да бъдат записани обратно в него, преди страницата да се покаже в браузъра.

Page_Unload – извиква се при приключване на рендирането на страницата. Използва се за освобождаване на ресурси.

Свойството IsPostBack

В ASP.NET предназначението на формите е да връщат информация обратно към сървъра за обработка. Този процес се нарича "postback". Със свойството IsPostBack на класа Page може да се провери дали страница се зарежда за пръв път. Ако IsPostBack е true, трябва да се изпълни първоначалния инициализационен код, а ако е false (т.е заявката е предизвикана от контрола на страницата), да се изпълни код, който отговаря на събитието, предизвикало връщането на страницата.

Ако страницата се инициализира с код, който трябва да се изпълни само веднъж (например попълване на DataSet от базата данни), винаги проверявайте дали тя се отваря за първи път или е в резултат на postback!

Ето един пример:

private void Page_Load(object sender,

System.EventArgs e)

{

if (!Page.IsPostBack)

{

// Еxecutes only on initial page load

// Initialize controls here

}

// This executes on every request

// Controls are already initialized

}

Свойството AutoPostBack

Ако искате новата стойност на контролата да бъде незабавно изпратена на сървъра, без да чакате потребителят да натисне на някой бутон, можете да укажете стойност true на свойството AutoPostBack на контролата. В момента, в който потребителят промени стойността на контролата, информацията ще се изпрати на сървъра. Сървърът осъвременява контролите на страницата и ги връща на клиента. Така страницата става по-гъвкава и интерактивна.

В следващия примерен HTML код ListBox контролата използва свойството AutoPostBack. Всеки път, когато потребителят променя стойността й, страницата се праща на сървъра автоматично и възниква събитието SelectedIndexChanged (т.е., ако има метод, асоцииран с него, той ще се изпълни):

<asp:DropDownList id="ListBox1" runat="server"

AutoPostBack="True">

<asp:ListItem>First Choice</asp:ListItem>

<asp:ListItem>Second Choice</asp:ListItem>

</asp:DropDownList>

Добавяме и код в code-behind страницата, който да покаже новоизбраната стойност в текстово поле:

private void ListBox1_SelectedIndexChanged

(object sender, System.EventArgs e)

{

TextBox1.Text = ListBox1.SelectedItem.Value;

}

HTML escaping проблеми

Когато получаваме данни от клиент, трябва винаги да проверяваме дали специалните знаци в текстовите променливи са описани правилно.

В HTML езика, знаците за по-малко и по-голямо ('<' и '>') са специални символи и браузърите интерпретират думата между тях като оператор или команда. Понякога се налага да използваме тези знаци като част от текст. За да визуализираме такъв знак, трябва да използваме специално записване (escaping). Тази техника се нарича escaping, защото често се реализира с поставяне на обратно наклонена черта ('\') преди знака.

Например знаците за по-малко и по-голямо ('<' и '>') се записват така: < и > (lt = less than, gt = greater than).

В HTML записването на един или повече интервала винаги се възприема като един интервал и визуално се представя като един интервал. Ако искате да поставите повече от един интервал, използвате специалния знак &nbsp; (nbsp = nonbreaking space).

За повече информация погледнете "The HTML Coded Character Set" (http://www.w3.org/MarkUp/html-spec/html-spec_13.html) в сайта на World Wide Web Consortium (W3C) или хипервръзките на края на тази глава.

Правилата за кодирането на специалните знаци създават потенциални проблеми при получаването на текстови данни от потребителя, които след това трябва да се изпишат в HTML страница.

HTML escaping проблеми – пример

Ето един прост пример, в който възниква escaping проблем:

string userName = "\"<script language='JavaScript'>while(1) alert('bug!')</script>";

Потребителят е изпратил горния символен низ. Ако го присвоим на TextBox няма да има проблеми:

TextBox1.Text = userName;

Ако обаче го присвоим на етикет, съдържанието му се интерпретира като HTML код и този код ще бъде изпълнен:

Label1.Text = userName;

Вместо да се изпише като текст в етикета, в браузъра се появява следното съобщение:

Решението на този проблем е да се използва статичният метод Server.HtmlEncode(…):

Label1.Text = Server.HtmlEncode(userName);

Сега всичко е както трябва. Ако разгледаме как е записан кодът в изходната HTML страница, ще забележим, че е била променена само първата кавичка:

<input name="InputTextBox" type="text" value="\"<script language='JavaScript'>while(1) alert('bug!');</script>" …>

Свързване с данни (Data binding)

ASP.NET предлага нов декларативен синтаксис за свързване с данни (data binding). Този изключително гъвкав синтаксис позволява свързването не само с бази от данни, но и със свойства, колекции, изрази, дори резултати от методи. В HTML-подобния код на уеб формите свързването на данните става в секции от вида <%# %>. Ето няколко примера:

- Със свойство:

Customer: <%# custID %>

- С колекция:

Orders: <asp:ListBox id="List1" datasource='<%# myArray %>' runat="server">

- С израз:

Contact: <%# ( customer.First Name + " " + customer.LastName ) %>

- С резултат от метод:

Outstanding Balance: <%# GetBalance(custID) %>

Как работи методът DataBind(…)?

Въпреки че изглежда подобен на <% Response.Write(customer.Name) %> или <%= customer.Name %>, поведението на методa е различно. Докато първите два блока се изпълняват когато страницата генерира HTML от Render(…) метода, ASP.NET изразите за свързване с данни се изпълняват при извикването на DataBind(…). Ако методът не се извика, целият регион <%#... %> се игнорира.

DataBind(…) е метод на класа Page и на сървър контролите. Когато се извика DataBind(…) на родителската контрола, той се извиква каскадно и за всички нейни деца. Извикването на DataBind(…) на вградения обект Page (Page.DataBind(…) или по-просто DataBind(…)), предизвиква оценяването на всички изрази (<%#... %>) за свързване с данни. Най-често DataBind(…) се извиква от Page_Load събитието:

void Page_Load(Object sender, EventArgs e)

{

Page.DataBind();

}

Може да се използва почти навсякъде в декларативната част на .aspx страница, стига да се връща подходящ тип данни. В някои случаи се налага преобразуване на данните.

Свързване на контроли с данни – пример

Първият пример за свързване с данни, който ще разгледаме, работи директно със свойства на страницата. Ето кода:

<html>

<body>

<h3><font face="Verdana">Свързване с данни (DataBinding)

към свойство на страницата</font></h3>

Customer: <b>|<%# custID %>|</b><br>

Open Orders: <b>|<%# orderCount %>|</b>

</form>

</body>

</html>

Ето и кода в code-behind страницата:

void Page_Load(Object sender, EventArgs e)

{

Page.DataBind();

}

string custID

{

get

{

return "Porsche";

}

int orderCount

{

get

{

return 911;

}

Ето го резултатът:

Важно е да извикаме метода Page.DataBind(). Ако го закоментираме, ето какво се случва:

Както виждаме, нищо не е изписано между вертикалните черти.

В следващия пример една контрола ще достъпва данни от друга контрола. В конкретния случай етикет (Label) ще изписва избрания щат от падащ списък. Ето го кода:

<html>

<body>

Свързване с данни (DataBinding) към свойство на друга

сървърна контрола

<asp:DropDownList id="DropDownListState" runat="server">

<asp:ListItem>CA</asp:ListItem>

<asp:ListItem>IN</asp:ListItem>

<asp:ListItem>KS</asp:ListItem>

<asp:ListItem>MD</asp:ListItem>

<asp:ListItem>MI</asp:ListItem>

<asp:ListItem>OR</asp:ListItem>

<asp:ListItem>TN</asp:ListItem>

<asp:ListItem>UT</asp:ListItem>

</asp:DropDownList>

<asp:Button Text="Submit" OnClick="ButtonSubmit_Click"

runat="server" ID="ButtonSubmit" Name="Button1" />

Selected State:

<asp:Label text='<%# StateList.SelectedItem.Text %>'

runat=server ID="LabelState" Name="LabelState"/>

</form>

</body>

</html>

Разбира се, в Page_Load метода извикваме DataBind(…). Резултатът е:

В третия пример ще заредим падащ списък от масив. Нека имаме уеб форма с падащ списък на нея. За краткост ще дадем кода само от code-behind класа:

void Page_Load(Object Sender, EventArgs E)

{

if (!Page.IsPostBack)

{

ArrayList values = new ArrayList();

values.Add ("IN");

values.Add ("KS");

values.Add ("MD");

values.Add ("MI");

values.Add ("OR");

values.Add ("TN");

DropDownListCountries.DataSource = values;

DropDownListCountries.DataBind();

}

void ButtonSubmit_Click(Object sender, EventArgs e)

{

LabelChosen.Text = "You chose: " +

DropDownListCountries.SelectedItem.Text;

}

От този код падащият списък се зарежда с няколко щата. Вторият метод изписва в етикет избрания щат.

Сега ще демонстрираме показване на данни в DataGrid от табличен източник на данни (в случая DataView):

<%@ Import namespace="System.Data" %>

<html>

<head>

void Page_Load(Object sender, EventArgs e )

{

if (!Page.IsPostBack)

{

DataTable dt = new DataTable();

DataRow dr;

dt.Columns.Add(new DataColumn("IntegerValue",

typeof(Int32)));

dt.Columns.Add(new DataColumn("StringValue",

typeof(string)));

dt.Columns.Add(new DataColumn("DateTimeValue",

typeof(DateTime)));

dt.Columns.Add(new DataColumn("BooleanValue",

typeof(bool)));

for (int i= 1; i <= 9; i++)

{

dr = dt.NewRow();

dr[0] = i;

dr[1] = "Item " + i.ToString();

dr[2] = DateTime.Now;

dr[3] = (i % 2 != 0) ? true : false;

dt.Rows.Add(dr);

}

dataGridExample.DataSource = new DataView(dt);

dataGridExample.DataBind();

}

</script>

</head>

<body>

<h3><font face="Verdana">Свързване с данни (DataBinding) на

DataView</font></h3>

<asp:DataGrid id="dataGridExample" runat="server" … />

</form>

</body>

</html>

При компилирането му се показват данните в браузъра:

В последния пример ще направим свързване на данни с изрази (expressions) и методи, които ще извикваме параметрично:

<html>

<head>

void Page_Load(Object Src, EventArgs E)

{

if (!Page.IsPostBack)

{

ArrayList values = new ArrayList();

values.Add (0);

values.Add (1);

values.Add (2);

values.Add (3);

values.Add (4);

values.Add (5);

values.Add (6);

DataListExample.DataSource = values;

DataListExample.DataBind();

}

String EvenOrOdd(int number)

{

if ((number % 2) == 0)

return "Even";

else

return "Odd";

}

</script>

</head>

<body>

Свързване с данни (Databinding) към методи и изрази

<asp:DataList id="DataListExample" runat="server" … >

Number Value: <%# Container.DataItem %>

Even/Odd: <%# EvenOrOdd((int) Container.DataItem) %>

</ItemTemplate>

</asp:datalist>

</form>

</body>

</html>

Този път данните се показват в DataList, в шаблона, на който се показват данните от целочислен масив и извикванията от метод. На метода се подава поредната целочислена стойност. Забележете гъвкавостта на работата с данни – можем да вземем поредния запис от база от данни и на негова основа да покажем допълнителни стойности или изцяло променени данни.

Работа с бази от данни от ASP.NET

В практиката при почти всички уеб приложения се налага работа с данни. Типичният сценарий включва визуализация на таблични данни, идващи от таблици в базата данни, както и добавяне на нови записи и редактиране и изтриване на съществуващи. Такива приложения обикновено се изграждат чрез свързване на ASP.NET уеб форми с ADO.NET.

Преди да изясним по какъв начин можем да изграждаме уеб приложения, използващи релационни бази от данни, нека си припомним основните концепции от ADO.NET. Ще направим само общ обзор на взаимодействието между ASP.NET и ADO.NET. За повече подробности за ADO.NET и работата с бази от данни, разгледайте главата, посветена специално на тази тема.

Обзор на ADO.NET

При създаването на уеб сайтове, които трябва да поддържат хиляди едновременни посещения от хиляди потребители, ще са нужни същия брой отворени връзки към базата от данни. Дори сървърите, отговарящи за поддръжката на базата от данни, да успеят да издържат на това натоварване, скоростта, с която ще работи приложението, ще е нетърпимо бавна. Затова е силно препоръчително при работа с бази от данни с ASP.NET да се използва несвързаният модел.

Обекти за работа с бази от данни

В главата за ADO.NET тези обекти са подробно обяснени, затова тук само ще ги споменем и ще отбележим как се използват в ASP.NET.

- Connection – връзка към базата от данни.

- Command – команда, служеща за изпълняване на заявки върху базата от данни и за извличане на данни.

- DataReader – четец на данни, върнати като резултат от заявка от базата от данни.

- DataSet – кеш на част от базата от данни в паметта. Съдържа таблици, релации, ограничения и т.н.

- DataAdapter – средство за извличане на данните от базата и обновяването им чрез DataSet обекти.

Визуализиране на данни

Почти всяко уеб приложение, което ползва база от данни, има нужда да представи тези данни на потребителя. Когато се отнася до единични полета (пр. потребителско име или дата) се използват етикети или литерали. Какво обаче да правим, ако искаме да покажем списъка на всички потребители с техните детайли под формата на таблица? Или ако искаме да ги покажем в падащо меню? За да реализираме тези и много други манипулации можем да използваме т.нар. свързани контроли (bound controls). Те играят важна роля в разработката на уеб приложения, защото позволяват бърза и интуитивна работа.

Ще разгледаме два вида свързване на данните – просто и сложно, както и най-важните свързани контроли.

Свързване на данни (data binding)

Свързването на данни е процесът на динамично извличане на данни от зададен източник и визуализирането им чрез подходящи контроли.

За различните контроли източникът на данни се задава чрез различни свойства - Text, DataSource, DataTextField. След малко ще обясним как се използват тези свойства при различните свързани контроли.

Трябва да отбележим, че в някои случаи (например при използването на свойството DataSource), свързване не се извършва, преди да се извика методът DataBind().

Източниците на данни за свързаните контроли могат да са разнородни, не само данни от бази от данни. Източник на данни може да е всеки обект от клас, имплементиращ интерфейса ICollection. Имплементацията на този интерфейс дава всичко необходимо, за да се извърши свързването на данните. Като резултат от това, можем да използваме като източници на данни за свързани контроли всяка една от следните структури:

- Класове от .NET Framework, които имплементират ICollection: масиви, списъци (сортирани или свързани), хеш таблици, стекове, опашки, речникови колекции.

- Потребителски класове, имплементиращи интерфейса ICollection или някой производен на него (примерно IList).

- Класове, свързани с работата с бази данни – DataTable и DataSet. Тъй като обект от тип DataSet може да съдържа много DataTable обекти след като укажем на DataSource свойството DataSet обекта, трябва да зададем на свойството DataMember името на таблицата, която искаме да свържем.

- Филтрирани подмножества от редовете на една DataTable таблицата: обекти от тип DataView.

Не можем директно да зададем като източник на данни за свързване XML документ. Трябва да заредим съдържанието на документа в една от споменатите по-горе структури, за да се възползваме от свързването на данни.

Просто свързване

Простото свързване указва връзка между някакви данни и свойство на някоя контрола. Тази връзка се задейства при извикването на метода DataBind() на форма или контрола, когато свързващият израз се оценява и се прилага.

Свързващ израз представлява всеки текст, заграден в таговете <%# и %>. Свързващи изрази можем да поставяме навсякъде в .aspx (.ascx) файла на уеб форма/контрола. Най-често те заместват стойността на някой атрибут на контрола. Ограждат се с единични кавички, за да се отличават от атрибутите, които са с двойни кавички:

<asp:Button ID="btnName" Runat="server"

Text='<%# "Бай Иван" %>' />

Ако създадем нова уеб форма, поставим в нея гореописания бутон и натиснем [F5], ще забележим, че като текст на бутона не се показва нищо. Това е така, защото не сме извикали метода DataBind(). За да проработи горният пример, трябва да извикаме този метод, примерно при обработчика на събитието Load на формата:

private void Page_Load(object sender, System.EventArgs e)

{

this.DataBind();

}

Горният пример не би се използвал в практиката, защото бихме постигнали същия ефект директно с Text="Бай Иван". Ползите от такъв синтаксис се виждат в случаите, когато за свързващ израз указваме по-сложен израз. В израза могат да се викат методи на езика, на който се компилира страницата, например:

<asp:textbox id="txtFirstName" runat="server"

Text='<%# GetData("FirstName") %>' />

<asp:textbox id="txtLastName" runat="server"

Text='<%# GetData("LastName") %>' />

Трябва да направим уточнение, че методите, участващи в израза, трябва да са достъпни във формата. Формата е наследник на code-behind класа и следователно не можем да извикаме от нея частен (private) метод на code-behind класа. Затова щом дефинираме методи, които искаме да извикваме от формата, трябва да им укажем видимост public, или protected. Ето пример:

public string GetData( string fieldName )

{

switch (fieldName)

{

case "FirstName":

{

return "Иван";

}

break;

case "LastName":

{

return "Иванов";

}

break;

default:

{

return "Unknown";

}

break;

}

Сложно свързване

Много често ни се налага да визуализираме голямо количество данни, извлечени от база от данни. Сложното свързване представлява свързване на множество редове/свойства с една контрола. Използва се предимно в списъчните и итериращите контроли, които ще разгледаме по-долу.

Контроли за показване на данни

Можем условно да разделим контролите за показване на данни в две групи - списъчни и итериращи.

Списъчни контроли

Списъчните контроли са DropDownList, CheckBoxList, RadioButtonList и ListBox. Фигурирането на думата List (списък) в името им, показва че служат за представяне на данните под формата на списък. Нека разгледаме какви са общите неща между тях.

Базовият клас ListControl

Класовете на списъчните контроли произлизат от един и същ абстрактен базов клас – ListControl. Той осигурява голяма част от функционалността на списъчните контроли.

Всяка списъчна контрола съдържа колекция Items. Тази колекция отговаря за елементите на списъка. Всеки елемент на списъка е от тип ListItem и има три свойства, които го характеризират – Text, Value и Selected. Полето Text съдържа текста, който да се покаже. Полето Value съдържа стойността на съответния елемент. Примерно можем да покажем списък с имената на държавите България, Германия, Русия, САЩ, и да използваме за ключова стойност техните държавни кодове – BGR, DEU, RUS, USA. Полето Selected съдържа булева стойност, показваща дали съответният елемент на списъка е избран.

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

Текущ избран елемент в списъчни контроли

За работа с избраните елементи се използват свойствата SelectedIndex, SelectedItem и SelectedValue:

- SelectedIndex връща индекса на първия избран елемент от списъка. Ако няма такъв, връща -1. Стойността на това поле може да се задава програмно.

- SelectedItem връща първия избран елемент от списъка. Ако няма такъв, връща null.

- SelectedValue връща стойността на първия избран елемент от списъка. Ако няма такъв, връща null. Може да използваме това поле, когато искаме да зададем програмно на някоя списъчна контрола избран елемент, но не знаем на коя позиция се намира в списъка. Например, ако имаме списък с всички държави и искаме България да е избрана, но не знаем на коя позиция се намира. Тогава задаваме като стойност на полето SelectedValue – "BGR".

Всички списъчни контроли имат събитие SelectedIndexChanged. То се предизвиква при промяна на индекса на първия избран елемент.

Елементите на списъчните контроли могат да се дефинират основно по три начина: декларативно (директно в .aspx/.ascx файла), динамично (като се добавят един по един в изпълним код), и чрез свързване (като съответната списъчна контрола се свърже с някой източник на данни). Ще демонстрираме всеки един от трите метода.

Списъчни контроли и свързване с данните

Всички списъчни контроли имат едни и същи свойства, отговарящи за свързването с източници на данни - DataSource, DataTextField, DataValueField, DataTextFormatString и DataMember:

- DataSource определя източника на данни.

- DataTextField определя стойностите на кое поле от източника на данни да се използват за стойности на полето Text за елементите на списъка.

- DataValueField определя стойностите на кое поле от източника на данни да се използват за стойности на полето Value за елементите на списъка.

- DataTextFormatString определя какъв форматиращ низ да се използва за визуализиране на текста. В случай, че източникът на данни е от тип DataSet, съдържащ повече от един DataTable обект, се използва полето DataMember, което задава коя точно таблица да се използва.

Контролата DropDownList

Контролата DropDownList показва данните под формата на падащ списък, от който може да се избира само един елемент:

Всеки един от елементите на списъка е обект от тип ListItem. Нека покажем как става тяхното дефиниране за DropDownList контролата в горния пример. Има три основни начина: декларативно (статично), динамично и чрез свързване на данни (data binding).

Декларативно (статично) задаване на елементите в списъчни контроли

Декларативното (известно още като статично) задаване на елементите в списъчни контроли е най-простият вариант да заредим данни в списъчна контрола. То става чрез дефинираме елементите директно в .aspx (.ascx) файла:

<asp:DropDownList ID="ddlList" Runat="server">

<asp:ListItem Value="1">Мечо Пух</asp:ListItem>

<asp:ListItem Value="2">Тигър</asp:ListItem>

<asp:ListItem Value="3">Прасчо</asp:ListItem>

<asp:ListItem Value="4">Йори</asp:ListItem>

</asp:DropDownList>

Динамично задаване на елементите в списъчни контроли

При динамичното задаване на елементите в списъчни контроли се използва свойството Items.

Ето един пример. Дефинираме контролата в .aspx (.ascx) файла:

<asp:DropDownList ID="ddlList" Runat="server">

</asp:DropDownList>

След това динамично добавяме елементите в кода:

ddlList.Items.Add(new ListItem("Мечо Пух", "1"));

ddlList.Items.Add(new ListItem("Тигър", "2"));

ddlList.Items.Add(new ListItem("Прасчо", "3"));

ddlList.Items.Add(new ListItem("Йори", "4"));

Задаване на елементите в списъчни контроли чрез свързване на данни

Свързването на данни със списъчна контрола се използва най-често, когато данните идват от базата данни. То се реализира малко по-сложно в сравнение със статичното и динамичното задаване на елементите.

Започваме с указване на източника на данни, като ще използваме два различни типа. Първият ще бъде масив от потребителски обекти, а вторият DataSet, съдържащ DataTable.

Потребителският клас, от който ще се състои масивът, изглежда така:

public class Character

{

private string name;

private long id;

public string Name

{

get { return name; }

set { name = value; }

}

public long ID

{

get { return id; }

set { id = value; }

}

public Character(string name, long id)

{

this.name = name;

this.id = id;

}

Дефинираме контролата в .aspx или.ascx файл:

<asp:DropDownList ID="ddlList" Runat="server"

DataTextField="Name" DataValueField="ID">

</asp:DropDownList>

Изкуствено ще създадем масив от елементи Character (на практика този масив може е извлечен от база от данни):

Character[] bookCharacters = new Character[]

{

new Character("Мечо Пух", 1),

new Character("Тигър", 2),

new Character("Прасчо", 3),

new Character("Йори", 4)

};

ddlList.DataSource = bookCharacters;

ddlList.DataBind();

В последните два реда от примера, масивът bookCharacters се задава като източник на данни за DropDownList контролата и се извиква методът DataBind(), за да се свържат данните с нея.

За да демонстрираме свързване с DataSet обект, ще се наложи и него да създадем изкуствено. Нека дефинираме отделен метод, който връща обект от тип DataSet:

public DataSet GetDataSource()

{

DataSet dataSource = new DataSet();

DataTable charactersTable = new DataTable("Characters");

Characters.Columns.Add("ID", typeof(long));

Characters.Columns.Add("Name", typeof(string));

DataRow row1 = charactersTable.NewRow();

DataRow row2 = charactersTable.NewRow();

DataRow row3 = charactersTable.NewRow();

DataRow row4 = charactersTable.NewRow();

row1["Name"] = "Мечо Пух";

row1["ID"] = 1;

row2["Name"] = "Тигър";

row2["ID"] = 2;

row3["Name"] = "Прасчо";

row3["ID"] = 3;

row4["Name"] = "Йори";

row4["ID"] = 4;

charactersTable.Rows.Add(row1);

charactersTable.Rows.Add(row2);

charactersTable.Rows.Add(row3);

charactersTable.Rows.Add(row4);

dataSource.Tables.Add(charactersTable);

return dataSource;

}

Дефинираме контролата в .aspx или.ascx файла:

<asp:DropDownList ID="ddlList" Runat="server"

DataSource='<%# GetDataSource() %>' DataTextField="Name"

DataValueField="ID" DataMember="Characters">

</asp:DropDownList>

В примера по-горе като стойност на свойството DataSource сме задали свързващ израз, който извиква функцията GetDataSource(). Свързващ израз може да се задава само за това поле на списъчна контрола. Указали сме също и стойността на свойството DataMember да е "Characters" – името на таблицата от DataSet обекта, която служи за източник на данни. В случая DataSet обектът има само една таблица и полето DataMember може да бъде пропуснато, но сме го дали за пълнота.

Контролата CheckBoxList

Тази контрола показва данните под формата на списък от CheckBox контроли, от който могат да се избират произволен брой елементи. Ето как изглежда тя:

Начините, по които могат да се зададат елементите на списъка, са аналогични на тези за DropDownList контролата. Допълнителните характеристики за CheckBoxList се определят чрез полетата RepeatColumns, RepeatDirection и RepeatLayout:

- Чрез свойството RepeatColumns се задава в колко колони да се покаже списъкът (по подразбиране в една).

- Свойството RepeatDirection определя в каква посока да се подреждат елементите на списъка - Vertical (по подразбиране) или Horizontal.

Нека дефинираме контролата така:

<asp:CheckBoxList ID="chkCharactersList" Runat="server"

RepeatColumns="2" RepeatDirection="Vertical">

<asp:ListItem Value="1">Мечо Пух</asp:ListItem>

<asp:ListItem Value="2">Тигър</asp:ListItem>

<asp:ListItem Value="3">Прасчо</asp:ListItem>

<asp:ListItem Value="4">Йори</asp:ListItem>

</asp:CheckBoxList>

В този случай резултатът ще бъде следният:

Ако свойството RepeatDirection има стойност Horizontal, вместо Vertical, то резултатът ще е следният:

Свойството RepeatLayout отговаря за начина, по който се представят елементите на списъка. То може да приема само две стойности – Flow и Table. Стойността му по подразбиране е Table. Ако стойността е Flow[,], за да се представят елементите на различни редове (един под друг), след последния елемент на всеки ред се поставя <br>, за да се премине на следващия. Ако стойността е Table, елементите се представят в таблична структура.

Контролата RadioButtonList

Разликите между CheckBoxList и RadioButtonList са в начина на представяне на данните и в броя на елементите, които могат да се избират едновременно.

При RadioButtonList елементите на списъка се представят така:

Само един елемент от списъка може да бъде избран.

Начините за дефиниране на елементите на списъка и свойствата на контролата са същите, както при CheckBoxList.

Контролата ListBox

Тази контрола показва данните под формата на списък, поставен в кутия.

Има две свойства, които характеризират тази контрола: Rows и SelectionMode:

- Стойността на полето Rows определя от колко реда се състои кутията. Ако елементите на списъка са повече от тази стойност, отдясно на кутията се появява плъзгаща се лента (ScrollBar).

- Свойството SelectionMode може да приема само две стойности – Single и Multiple. Ако стойността му е Single, то от списъка може да се избира само един елемент. В противен случай може да се извършва множествена селекция.

Итериращи контроли

Списъчните контроли предоставят базовата функционалност, необходима на едно уеб приложението да комуникира успешно с потребителя. Чрез тях данните се показват на потребителя и той може да направи избор от тях.

В много случаи е удачно тези данни да се представят в табличен вид. Например, ако работим с база от данни и искаме нашето приложение да визуализира всички данни от дадена таблица.

Старият начин за итерация

Нуждата от визуализиране на данни в таблична форма не е нещо ново. В класическото ASP (преди появата на ASP.NET) се ползваше следния начин на реализация:

<tr>

int dataItemsCount = Data.Tables[0].Rows.Count;

int dataColumnsCount = Data.Tables[0].Columns.Count;

for(int i=0; i < dataColumnsCount; i++)

{

<td align="center"

style="background-color: #00AAFF; padding: 5px;">

<b>

<%= Data.Tables[0].Columns[i].ColumnName %>

</b>

</td>

<% }%>

</tr>

for(int i = 0; i< dataItemsCount; i++)

{

for(int j = 0; j< dataColumnsCount; j++)

{

<%= Data.Tables[0].Rows[i][j].ToString()%>

</td>

<% }%>

<tr>

<% }%>

</table>

В примера по-горе сме използвали обекта Data, който е от тип DataSet. Тъй като и за напред ще ни се наложи да го използваме в различни примери, нека зададем следната дефиниция за Data:

private DataSet dsData;

public DataSet Data

{

get

{

return dsData;

}

private void Page_Load(object sender, System.EventArgs e)

{

GenerateDataSet();

}

private void GenerateDataSet()

{

dsData = new DataSet();

DataTable dtData = new DataTable("Characters");

dtData.Columns.Add("Character First Name");

dtData.Columns.Add("Character Last Name");

dtData.Columns.Add("Character Birth Date", typeof(DateTime));

dtData.Columns.Add("Character Age", typeof(Int32));

DataRow drData = dtData.NewRow();

drData["Character First Name"] = "Мечо";

drData["Character Last Name"] = "Пух";

drData["Character Birth Date"] = new DateTime(1971,4,1);

drData["Character Age"] = 35;

dtData.Rows.Add(drData);

drData = dtData.NewRow();

drData["Character First Name"] = "Прасчо";

drData["Character Last Name"] = "Свински";

drData["Character Birth Date"] = new DateTime(1978,5,11);

drData["Character Age"] = 28;

dtData.Rows.Add(drData);

drData = dtData.NewRow();

drData["Character First Name"] = "Тигър";

drData["Character Last Name"] = "Бенгалски";

drData["Character Birth Date"] = new DateTime(1984,8,12);

drData["Character Age"] = 21;

dtData.Rows.Add(drData);

drData = dtData.NewRow();

drData["Character First Name"] = "Йори";

drData["Character Last Name"] = "Магарисченко";

drData["Character Birth Date"] = new DateTime(1955,4,30);

drData["Character Age"] = 51;

dtData.Rows.Add(drData);

dsData.Tables.Add(dtData);

}

Дефинираме обекта Data като свойство на страницата, което връща член-променливата dsData. По време на зареждане на страницата (Page_Load) извикваме метода GenerateDataSet(). Той инициализира dsData с примерни данни. За простота тук данните не се вземат от база от данни, но това е без значение за целите на демонстрацията.

Как работи примерът?

Да се върнем обратно към примера. Ако сте разработвали приложения с ASP, този пример сигурно ви се струва донякъде познат. За тези, които тепърва започват да се запознават с разработка на уеб приложения с ASP.NET, кодът сигурно изглежда изключително объркващ. Няма да се задълбочаваме в детайли, а ще обясним само ключовите части на примера.

Както сте забелязали, тук по особен начин се смесват сървърни тагове (<% %>) и обикновен HTML. Нека разгледаме следния отрязък код:

<b>Character List</b> <br />

<% for(int i = 0 ; i < 10; i++)

{

Character <%= (i+1)%>

<% if((i % 2)> 0) { %> </i> <% }%> </b>

<br />

<% } %>

<b>Total : 10</b>

В резултат на интерпретирането на този код, в уеб браузъра на клиента ще пристигне следният HTML:

<b>Character List</b> <br />

<b>

Character 1

</b>

<br />

<b> <i>

Character 2

</i> </b>

<br />

<b>

Character 3

</b>

<br />

<b> <i>

Character 4

</i> </b>

<br />

<b>

Character 5

</b>

<br />

<b> <i>

Character 6

</i> </b>

<br />

<b>

Character 7

</b>

<br />

<b> <i>

Character 8

</i> </b>

<br />

<b>

Character 9

</b>

<br />

<b> <i>

Character 10

</i> </b>

<b>Total : 10</b>

В крайна сметка браузърът ще покаже следния списък:

Примерният код се интерпретира така: за всяка стойност на i от 0 до 9 се изпълнява тялото на цикъла. В него всичко, което не е заградено в сървърни тагове (<% %>) остава непроменено, а всичко заградено в сървърни тагове се интерпретира.

Този опростен пример демонстрира как може да се реализира повторение на HTML елементи. В първоначалния пример вместо фиксирана стойност 10 използваме dataColumnsCount и dataItemsCount.

Този начин на реализация на представяне на данни в табличен вид е твърде непрактичен, но преди ASP.NET не е имало друга алтернатива. Основните му недостатъци идват от необходимостта от смесването на процедурен код и HTML, което води до нечетливост на написаното и затруднения в поддръжката.

Нуждата от начин за представяне на данните в табличен вид е довела до създаването на контролите DataGrid, DataList и Repeater.

Сходства между итериращите контроли

Всички итериращи контроли съдържат списък с елементи, отговорни за генерирането на изходния HTML.

DataGrid показва записите в HTML таблица (чрез тага <table>), където всеки елемент се представя в отделен ред. Класът DataGridItem е предназначен да визуализира табличен запис и затова е наследник на класа TableRow.

Аналогично DataList е съставен от елементи от тип DataListItems. Класът Repeater, от друга страна, позволява пълна настройка на изходния HTML. Затова класът за елементите му RepeaterItem не е наследник на TableRow.

При извикване на метода DataBind() се преминава през всички записи на свойството DataSource. За всеки запис се създава нова инстанция от тип DataWebControlNameItem и записът се свързва със свойството й DataItem.

Събития на итериращите контроли за свързване с данните

Итериращите контроли поддържат няколко общи събития, касаещи процеса на свързването на данните:

- Събитието ItemCreated се активира за всеки нов DataWebControlNameItem добавен към контролата, преди още да е инициализирано свойството DataItem. Събитието ItemDataBound се случва веднага след инициализацията на свойството DataItem. А ItemCommand събитието се активира при всяка команда от Button or LinkButton в итериращата контрола.

- Друга важна обща характеристика на итериращи контроли е, че всички позволяват използването на шаблони. Контролите DataList и Repeater задължително изискват шаблони, докато при DataGrid използването им е незадължително.

- DataGrid и DataList са наследници на класа WebControl, докато Repeater е наследник на класа Control. Класът WebControl има множество свойства свързани с визуализацията: BackColor, ForeColor, CssClass, BorderStyle и др. Repeater контрола не поддържа директно тези свойства, но аналогични форматиращи настройки могат да бъдат указвани чрез шаблоните му.

Контролата DataGrid

От гледна точка на вградени възможности, DataGrid е най-мощната от итериращите контроли. За сметка на това, тя не е гъвкава по отношение на генерирания HTML код. Той винаги генерира HTML таблици, като за всяка свързана колона се създава ред чрез тага <tr> и за всяко поле от записа, се създава колона чрез тага <td>.

Сред вградените възможности на DataGrid контролата са сортиране, страниране и редакция на данните директно в таблицата. Примерно чрез указване на свойството AllowSorting = true и малко допълнителен код, лесно може да се предостави на потребителя средство за сортиране.

С DataGrid можем много бързо да реализираме показване на данни в ASP.NET уеб страница. Само трябва да поставим контрола в страницата, да укажем DataSource и да извикваме DataBind(). DataGrid има свойство AutoGenerateColumns, с което може да укажем дали колоните се генерират автоматично, или дали само ще задаваме кои от тях да се покажат и по какъв начин.

Всяка колона в DataGrid е инстанция на клас, наследник на DataGridColumn. Вградените типове колони са:

- BoundColumn – колона, свързана с поле от източника на данни. Показва данните под формата на обикновен текст.

- ButtonColumn – колона, показваща бутон.

- EditColumn – колона за редакция на данни.

- HyperLinkColumn – колона, показваща хипервръзка, като текста и URL-то могат да бъдат от отделни полета на източника на данни.

- TemplateColumn – колона шаблон, чрез която може да се генерира произволен изходен HTML. Има шаблони за различните части на таблицата: ItemTemplate, HeaderTemplate, FooterTemplate и EditItemTemplate.

Производителността на DataGrid понякога може да е проблем, тъй като при голям обем данни размерът ViewState на контролата става значителен. Ако ViewState бъде изключен, то това ще е за сметка на възможностите за сортиране, страниране и редактиране.

Контролата DataList

Необходимостта от DataList възниква, когато представянето на данни в HTML таблица с по един запис на ред е неудачно. Понякога може да искаме да покажем повече от един запис на ред или да решим да използваме <span> вместо <table> тагове.

При DataList концепцията за "колони" не присъства. Всички настройки се задават чрез шаблони, в които разработчикът може да укаже комбинация от HTML и код за свързване с данните. Примерно следният ItemTemplate ще покаже полето Name от източника на данни:

<asp:DataList runat="server" id="lstCharacterNames">

<%# DataBinder.Eval(Container.DataItem, "Name") %>

</ItemTemplate>

</asp:DataList>

Можем лесно да разширим горния шаблон, за да покажем Name полето удебелено и под него да добавим поле ID:

<asp:DataList runat="server" id="lstCharacterNamesAndIDs">

<br/>

<%# DataBinder.Eval(Container.DataItem, "ID") %>

</ItemTemplate>

</asp:DataList>

За всеки запис в източника на данни на DataList, се рендира изходен HTML след като се оцени свързването, указано в ItemTemplate. Поддържат се следните типове шаблони:

- ItemTemplate – шаблон за елемента

- AlternatingItemTemplate – ако е указан, всеки следващ елемент от източника на данни, използва този шаблон вместо ItemTemplate.

- EditItemTemplate – шаблон на елемента в режим на редакция.

- HeaderTemplate – шаблон за заглавния елемент. Показва се само ако свойството ShowHeader е true.

- FooterTemplate - шаблон за заключителния елемент. Показва се само ако свойството ShowFooter е true.

- SelectedItemTemplate – шаблон за избран елемент

- SeparatorTemplate – шаблон, прилаган след всяко добавяне на DataListItem.

По подразбиране, DataList показва всеки елемент като ред в HTML таблица. Чрез свойството RepeatColumns можем да укажем колко елементи искаме да се съдържат на всеки ред. Можем чрез свойството RepeatLayout, което приема стойности Table или Flow, да зададем да се ползват <span> тагове вместо <table>, Тези допълнителни възможности правят DataList контролата по-гъвкава от DataGrid.

С шаблона EditItemIndex и събитията EditCommand, UpdateCommand и CancelCommand, контролата DataList също поддържа редактиране на място, но реализацията изисква повече програмиране от страна на разработчика. Още по-трудоемко е имплементирането на възможности за сортиране и страниране в DataList контрола.

Контролата Repeater

Контролата Repeater предлага максимална гъвкавост в рендирането на HTML. Тя е удачно решение, когато не искаме да използваме нито HTML <table>, нито серия от <span> тагове.

Repeater предлага следните пет шаблона, чиято функция вече ни е добре позната:

- AlternatingItemTemplate

- FooterTemplate

- HeaderTemplate

- ItemTemplate

- SeparatorTemplate

HeaderTemplate и FooterTemplate указват HTML, който да се покаже съответно преди и след данните, свързани с контролата. AlternatingItemTemplate и ItemTemplate указват HTML кода и свързващия синтаксис за рендиране на елементите от източника на данни.

Нека свързваме данни за героите от книгата "Мечо Пух" с Repeater контрола и едно от полетата е Name. Ако искаме да покажем списък с имената им в несортиран списък можем да използваме следния синтаксис:

<asp:Repeater runat="server" id="rptCharacterNames">

<ul>

</HeaderTemplate>

</ItemTemplate>

</ul>

</FooterTemplate>

</asp:Repeater>

Тъй като Repeater не е наследник на WebControl и не предлага свойства за указване на стила на форматиране, то ако искаме да покажем имената на героите с удебелен шрифт, трябва в ItemTemplate да добавим HTML тага <b>:

<li><b><%# DataBinder.Eval(Container.DataItem, "Name")

%></b></li>

</ItemTemplate>

Тази особеност на Repeater контролата води понякога до по-тежки, а следователно и по-трудно четими шаблони. Също така ако се наложи да реализираме сортиране и страничен преглед, трябва да го реализираме от нулата.

Предимствата на Repeater са в нейната гъвкавост и добра производителност.

Управление на състоянието

Уеб страниците се прехвърлят чрез HTTP протокола. Те не запазват състоянието си, тъй като не знаят дали заявките идват от един и същ клиент. Страниците се създават наново при всяко обръщение към сървъра. Ако не се използваха допълнителни механизми за управление на състоянието (state management), възможностите на уеб приложенията биха били много ограничени.

В класическите ASP приложения този проблем се решава по няколко начина, чрез: бисквитки (cookies), параметризирани адреси (query string), и чрез ASP обектите за приложение (application) и за сесия (session). В ASP.NET всички тези техники са на наше разположение, като възможностите им са обогатени в много отношения.

Подходите за управление на състоянието в уеб приложенията се разделят на две категории – от страна на клиента (Client-side) и от страна на сървъра (Server-side). При управление на състоянието от страна на клиента, сървърът не пази информацията информация между заявките, а тя се съхранява на страницата или на компютъра на клиента.

Първо ще разгледаме Client-side техники – бисквитки, параметризирани адреси, скрити полета и ViewState. След това ще направим обзор на сървърните механизми за управление на състоянието на ниво приложение и ниво сесия.

Бисквитки (Cookies)

Бисквитката (cookie) е малко парче информация, изпратена от уеб сървъра до клиентски браузър. Браузърът по подразбиране съхранява получената бисквитка и от него се очаква да я изпраща обратно към сървъра при всяка следваща заявка. Информацията в нея може да е произволна, стига цялостният размер на бисквитката (информацията и мета данни за самата бисквитка) да не надвишава 4 KB. Нека да разгледаме някои от свойствата, с които се характеризират бисквитките.

Свойства на бисквитките

Ето някои от по-важните свойства на бисквитките:

- Expires - указва кога изтича валидността на бисквитката. Ако не се укаже, бисквитката се запазва само в паметта. Ако това свойство се зададе, бисквитката се записва на твърдия диск и се пази за времето, което е указано. Когато браузърът изпраща дадена бисквитка, той проверява дали нейната валидност не е изтекла и ако така, той не я изпраща към сървъра, а я изтрива. Не трябва да забравяме, че потребителят може да изтрие бисквитката по всяко време.

- Domain – областта от интернет адреси, на които може да се праща бисквитката. По подразбиране това е адресът, от който е дошла, но може да се укаже и друго. Браузърът изпраща само бисквитките, предназначени за поискания интернет адрес.

- Path – път на адресите, до които може да се праща бисквитката. Бисквитката няма да се праща на адреси от по-високо ниво в дървото на директориите. Пример: ако пътят е /sites/stefan, тя няма да се прати на /sites/dido, нито на /sites, но ще се прати на /sites/stefan/pics. По подразбиране стойността на това свойство е виртуалната директория, от която първоначално е дошла бисквитката, но може и да се промени.

Механизъм на работа с бисквитки

За да разгледаме по-подробно механизмът на бисквитките, нека имаме примерна бисквитка с име UserID и стойност "StefanDobrev" – името на клиента. Нека датата на изтичане (свойството Expires) е 17-ти януари 2006 г., областта (свойството Domain) е devbg.org, а пътят (свойството Path) – главната виртуална директория.

Ето частта от HTTP хедъра, засягаща бисквитката, която ще се получи при клиента:

Set-Cookie: UserID=StefanDobrev; path=/; domain=devbg.org; Expires=Saturday, 17-Jan-06 00.00.01 GMT

Ако клиентският браузър е Internet Explorer, папката, в която ще се съхрани бисквитката, е \Documents and Settings\Username\Cookies, а файлът ще е с име: username@domainname.txt. В случая, ако потребителят на системата е sdobrev, файлът ще има име sdobrev@devbg.org[1].txt. При всяка следваща заявка към този домейн и път, указан в бисквитката, браузърът е длъжен да изпрати съдържанието на бисквитката в HTTP хедъра, който също изпраща. В случая това ще е:

Cookie: UserID: StefanDobrev;

Това изпращане ще продължи, докато е валидна бисквитката. Трябва да се има предвид, че потребителят може да настрои браузъра си, така че да не приема бисквитки.

Като структура бисквитките представляват таблица от наредени тройки от типа адрес-име-стойност. Браузърът разпознава сървъра по неговия URL адрес и изпраща само тези бисквитките, предназначени за него.

Приложения на бисквитките

Както вече знаем, HTTP протоколът не може да запази състоянието на дадена заявка (той е stateless протокол). Бисквитките могат да се използват да разберем дали заявките идват от един и същи клиент.

Чрез механизма на бисквитките, сървърът може да следи потребителя и да му връща персонализирано съдържание, спрямо неговите нужди, изисквания и интереси. Към това приложение може да причислим и възможността за проследяване поведението на потребителя и изграждане на карта на най-често посещаваните от него страници.

Друго тяхно приложение е за автоматично влизане на потребителя в дадена уеб базирана система при неговото следващо идване. Това е възможно поради факта, че бисквитките могат да останат неограничено дълго време при клиентския браузър.

Бисквитките в .NET Framework

В .NET Framework има два класа, които предоставят достъп за работа с бисквитки.

System.Net.Cookie се използва при направата на клиентски приложения, като им предоставя функционалността да четат бисквитките, върнати от дадена уеб заявка.

System.Web.HttpCookie се използва в ASP.NET за достъп до бисквитките в уеб приложение. Чрез свойството Cookies на класовете HttpResponse и HttpRequest имаме достъп до колекция, която съдържа всички бисквитки, изпратени от сървъра или върнати от клиента.

Пример – четене от бисквитка

С този пример ще илюстрираме как може да се извлече дадена бисквитка от клиентска заявка и да се използва стойност, съхранена в нея:

HttpCookie cookie = Request.Cookies["UserID"];

if ( cookie != null )

{

LabelUsername.Text = cookie["Username"];

LabelExpires.Text = cookie.Expires;

}

Скрити полета

Скритите полета са подобни на текстовите полета, но с тази разлика, че не се показват в браузърите. Когато една страници е пратена до сървъра, съдържанието на скритите полета се праща в HTTP Form колекцията, заедно със стойностите на другите полета. Скритото поле играе ролята на държател за информация, специфична за страницата.

Скритите полета като HTML елементи

Скритите полета в HTML (hidden) имат следните атрибути:

- name - вътрешно име на полето, служещо за идентификация

- value - стойност, която да бъда изпратена до сървъра.

Ето един пример:

Скритите полета в .NET Framework

ASP.NET предоставя контролата HtmlInputHidden, която предлага функционалността на скрито поле:

protected System.Web.UI.HtmlControls.HtmlInputHidden Hidden1;

// Аssign a value to Hidden field

Hidden1.Value = "invisible data";

// Рetrieve a value

string str = Hidden1.Value;

Особености на скритите полета

За да използвате скритите полета, трябва да употребите HTTP POST метода за пращане на уеб страници.

Също така имайте предвид, че стойността не е напълно скрита за потребителя. Той може да я види в сорс кода на страницата и дори да я промени. Това прави скритите полета неудачни за съхраняване на чувствителна и конфиденциална информация.

Параметризирани адреси (Query Strings)

Параметризираните адреси предоставят лесен, но ограничен, начин за поддържане на информация за състоянието.

Пример за параметризиран адрес

Един параметризиран URL адрес може да изглежда по следния начин:

http://asp.net/getstarted/default.aspx?tabid=61

Когато се получи заявка за getstarted/default.aspx, можем от нея лесно да извлечем кой таб е бил избран чрез следния код:

string selectedTabID = Request.Params["tabid"];

Особености при използването на параметризирани адреси

Параметрите в заявката са видими в URL адреса и на практика не осигуряват никаква сигурност.

Повечето браузъри поддържат до 255 знака в URL. Това значително ограничава приложението на този подход.

Технологията ViewState

ViewState (визуално състояние) е технология, чрез която може да се съхрани информация за състоянието на сървърните контроли и данни, въведени от потребителя при последователни заявки към една и съща страница. Традиционните HTML елементи са без състояние и не запазват нито данните, нито настройките от страна на клиента.

Нека си представим една уеб форма, състояща се от много на брой полета, които клиентът трябва да попълни. След попълването й трябва да валидираме въведената информация. Ако има неточности, потребителят е задължен отново да въведе цялата информация. Чрез технологията ViewState въведените от потребителя данни се запазват между заявките и не е нужно тяхното въвеждане да става отначало.

Сървърни контроли и ViewState

Благодарение на ViewState технологията, голяма част от сървърните контроли могат да запазват своето състояние (стойностите на отделните им свойства). Всяка динамична промяна на вътрешното състояние (промяна на свойство, свързване с данни и др.) на дадена сървърна контрола се запазва, за да може да бъде рендирана при клиента, когато има последователни заявки към една и съща страница.

ViewState като място за съхраняване на информацията

Освен за съхраняване вътрешното състояние на сървърните контроли ViewState може да се използва и за съхраняване на информация между няколко postback извиквания. Свойството ViewState на System.Web. UI.Control (базовия клас, който наследяват всички уеб контроли, включително и Page) предоставя достъп до речникова колекция от тип име-стойност, която може да се използва за съхраняване на информация.

Пример – съхраняване и извличане на данни от ViewState

Със следващия пример ще илюстрираме как може да съхраним информация във ViewState областта и след това да я извлечем от нея.

Запазване във ViewState:

ViewState["Username"] = TextBoxUsername.Text.Trim();

Извличане на вече съхранена информация от ViewState:

LabelUsername.Text = (string) ViewState["Username"];

Забележка: ако в речниковата колекция няма елемент със зададения ключ, се връща null.

Механизъм на работа на ViewState технологията

Всяка информация, добавена във ViewState (било то при динамична промяна на сървърна контрола или чрез свойството ViewState), се сериализира и се изпраща на клиента под формата на скрит HTML елемент със следния вид:

<input type="hidden" name="__VIEWSTATE"

value="dDw5NjU1MTU1O3Q8cDxsPFRydWU7PjtsPFZpemliaWxpd

Hk7Pj47Oz47Pm+DzsKPsEqi3imV9lUMfxhbK/Rc" />

Когато клиентът направи HTTP POST заявка към същата страница, съдържанието на скрития елемент се десериализира, възстановява се вътрешното състояние на сървърните контроли и се запълва речникова колекция, достъпна чрез ViewState свойството.

Сериализацията и десериализацията се извършват с помощта на класа LosFormatter, който е оптимизиран за работа с примитивни типове, символни низове, масиви и хеш-таблици.

Както вече отбелязахме, информацията, запазена във ViewState областта, се сериализира. Това означава, че ако искаме да запазим инстанция на дефиниран от нас потребителски клас, той трябва да е маркиран с атрибута [Serializable].

Стойността на скрития елемент __VIEWSTATE е BASE64 представяне на сериализираните контроли от формата. Въпреки че тази информация не е лесно четима, тя не е криптирана и може да бъде декодирана.

Не съхранявайте конфиденциална информация във ViewState!

За да се избегне фалшификация на ViewState информацията, всеки път, когато ASP.NET създава сериализирания ViewState, автоматично към него се добавя и хеш кодът му. При следваща заявка се проверява дали данните от ViewState имат същия хеш код (т.е. дали не са променени). Тази опция може да се изключи, като в директивата @Page зададем стойност false на атрибута EnableViewStateMac.

Поддържане на ViewState

Ако дадена уеб страница съдържа множество контроли, цялостният размер на ViewState областта може да нарасне драстично, което от своя страна увеличава размера на страницата, която се изпраща към клиента. В подобни случаи може да ограничим използването на ViewState само върху контролите, които се нуждаят от него. Например за контрола от тип Label, която има зададено свойство Text в aspx страницата и знаем, че това и останалите й свойства няма да се променят, е разумно да изключим ViewState-a. Това може да стане така:

<asp:Label ID="LabelName" Runat="server" Text="Stefan"

EnableViewState="False" />

Изключването на ViewState може да стане и на ниво страница:

<%@ Page EnableViewState="False" %>

Това е удобно, ако искаме да разрешим използването на ViewState само за определени контроли.

Запазване на ViewState в Session обекта

Когато обемът на информацията, съхранена във ViewState, нарасне, цялостният размер на HTML страницата, изпратена към клиента, също нараства. Това може да доведе до изпращане на страници с размер от около 0.5 – 1 МB, което не е препоръчително.

Един сценарий, в който е удачно да поддържаме малък ViewState е, когато разработваме приложения за мобилни клиенти. В тези ситуации е добре да го съхраняваме на друго място, като избегнем неговото рендиране при клиента и в същото време запазим състоянието. В примера ще покажем как това може да стане в Session обекта. За целта ще препокрием два от виртуалните методи на класа System.Web.UI.Page: LoadPageStateFrom PersistenceMedium() и SavePageStateToPersistenceMedium(…). Ето и кода, който осъществява това:

protected override object LoadPageStateFromPersistenceMedium()

{

return Session["ViewState"];

}

protected override void SavePageStateToPersistenceMedium(

object viewState)

{

Session["ViewState"] = viewState;

}

С този пример демонстрирахме как можем да контролираме механизма на записване и зареждане на ViewState информацията. Може да се използват и произволни други места за съхранение: бази от данни, файлове, собствени скрити полета и др.

Състояние на приложението

В рамките на ASP.NET приложение информация да бъде споделяна чрез класа HttpApplicationState (достъпван най-често чрез Application свойството на HttpContext обекта). Този клас ни предоставя речникова колекция, където можем да съхраняваме обекти и скаларни стойности, свързани с множество уеб заявки и клиенти.

При първата заявка към URL ресурс от виртуалната директория на ASP.NET приложение се създава инстанция на класа HttpApplicationState. По време на всяка заявка всички модули HttpModule и обработчици HttpHandlers (в това число ASP.NET страниците), имат достъп тази инстанция чрез свойството Application на HttpContext обекта.

За поддръжка на състояние на ниво приложение ASP.NET ни предоставя:

- Речникова колекция, достъпна за всички обработчици на заявки в приложението.

- Лесен механизъм за синхронизация до променливите на състоянието.

- Сигурност, че други ASP.NET приложения не могат да достъпват и променят състоянието на нашето приложението.

Използване на състоянието на приложението

Променливите на състоянието на Application обекта, са на практика глобални за ASP.NET приложение. Затова при вземане на решение дали да ги използваме, трябва да имаме предвид следните фактори:

- Памет - паметта не се освобождава докато променливата не бъде заменена или премахната. В някои случаи е лоша идея да се държат постоянно в паметта рядко достъпвани данни с голям размер.

- Нишкова безопасност – ако обектите, които съхраняваме, не са нишково обезопасени, то трябва да положим допълнителни усилия за синхронизиране на достъпа до тях.

- Скалируемост – при използване на заключвания за осигуряване на нишкова безопасност, операционната система блокира другите работещите нишки, чакащи за ресурса. Това може да доведе до значително падане на производителността на приложението.

- Възстановяване на данните – по време на изпълнение на приложението, домейнът на приложението може да бъде унищожен във всеки момент (в резултат на срив, промени в кода, планирано рестартиране на процеса, и др.). В такъв случай данните за състоянието на приложението ще бъдат загубени. Ако такова поведение е нежелателно, трябва да предприемем допълнително стъпки за решаване на проблема.

- Състоянието на приложението не е споделено в рамките на уеб ферма (приложение, изпълнявано на няколко сървъра) или уеб градина (приложение, изпълнявано на няколко процеса на един сървър). Променливите, съхранявани в състоянието на приложението, са глобални само в рамките на един процес.

Въпреки тези особености, променливите на ниво приложение могат да бъдат много полезни. В тях можем да пазим рядко извличана, но често достъпвана информация от бази от данни и така да подобрим значително скоростта на обработка на заявките. От друга страна, този ефект можем да бъде постигнат и с механизмите за кеширане в ASP.NET, които ще разгледаме по-късно.

Колекции за състоянието на приложението

Класът HttpApplicationState предоставя две колекции: Contents и StaticObjects.

Колекцията Contents дава достъп до променливите добавени по следния начин:

Application["AppStartTime"] = DateTime.Now;

Можем изрично да използваме свойството Contents:

Application.Contents["AppStartTime"] = DateTime.Now;

Колекцията StaticObjects предоставя достъп до променливите, дефинирани чрез <object runat="server"> тагове във файла Global.asax:

ID="MyInfo" PROGID="MSWC.MYINFO">

</object>

Можем да използваме така дефинираните обекти по следния начин:

<html>

</body>

Application Level Title: <%= MyInfo.Title %>

<body>

</html>

Синхронизация на достъпа до състоянието на приложението

Няколко нишки на приложението може едновременно да достъпват стойности, съхранени в състоянието на приложението. Следователно трябва да се погрижим да осигурим, че използваме тези променливи по безопасен начин.

За целта, класът HttpApplicationState предоставя два метода Lock() и Unlock(), които ограничават достъпа до променливите на приложението само до една нишка.

Извикване на Lock() метода на Application обекта кара ASP.NET да блокира опитите на нишките да достъпват състоянието на приложението, до извикване на Unlock().

Следният код демонстрира техниката на заключване:

Application.Lock();

Application["SomeGlobalCounter"] =

(int)Application["SomeGlobalCounter"] + 1;

Application.UnLock();

Ако не извикаме Unlock(), то заключването ще бъде премахнато автоматично щом приключи заявката, или при timeout, или при появяване на необработено изключение, което да прекрати обработката на отговора.

Състояние на сесиите

ASP.NET предоставя възможност за запазване на информация за взаимодействието с определен потребител между отделните заявки. При разработката на уеб приложения често се налага да реализираме такава функционалност. Типичен пример е уеб-базирана система за работа с електронна поща. При нея потребителите първо се идентифицират чрез потребителско име и парола, а след това системата ги "познава" до момента на затварянето на уеб браузъра или излизане от системата.

Вградените в ASP.NET възможности за поддръжка на потребителска сесия (session state) ни позволяват да:

- Идентифицираме и класифицираме автоматично в логическа сесия всички заявки, идващи от един и същ браузър.

- Запазваме данни на сървъра за сесията, с цел използването им между множество отделни заявки.

- Да обработваме в кода ни събития, свързани със сесията (Session_OnStart, Session_OnEnd, и т.н.).

- Автоматично да бъдат освобождаване данните за сесията, ако в определен период от време не се получи заявка от браузъра.

Поддръжката на сесии в ASP.NET се характеризира с:

- Леснота за ползване.

- Надеждно запазване на данни, устойчиво на рестартиране на IIS или на работния процес на ASP.NET.

- Скалируемост в уеб ферма и уеб градина.

- Възможност за функциониране и без HTTP бисквитки.

- По-добро бързодействие спрямо класическото ASP.

Забележка: Състоянието на сесиите не се запазва извън границите на едно уеб приложение.

Идентифициране на сесия

Всяка активна ASP.NET сесия се идентифицира и проследява чрез 120-битов низ SessionID. Той е съставен от ASCII символи и може да участва в URL адреси.

SessionID стойностите се генерират така, че да са уникални и достатъчно произволни, за да не може по идентификатор на нова сесия да се открие идентификатор на предишна.

SessionID низовете се прехвърлят между заявките чрез HTTP бисквитка или чрез включване в URL адресите, в зависимост от настройките на приложението.

Запазване на състоянието в рамките на сесия

ASP.NET позволява запазването на произволни данни за сесия в речникова колекция, която се съхранява в паметта на IIS процеса.

Когато използваме режим in-process, т.е. данните за сесията се пазят директно в ASP.NET процеса, трябва да имаме предвид, че те ще бъдат загубени ако aspnet_wp.exe или application domain бъдат рестартирани. Това може да случи в следните сценарии:

- Наличие на атрибут в елемента <processModel> на Web.config файла, който да доведе до стартиране на нов ASP.NET работен процес (примерно указан лимит на паметта).

- Промяна в Global.asax или Web.config файловете.

- Промени в \Bin директорията на уеб приложението.

В режим out-of-proc, вместо да се поддържат живи обекти в работния процес, т.нар. State Server съхранява състоянието в паметта, а работният процес се обръща при нужда към него. В режим SQL, състоянието на сесията се пази в SQL Server.

ASP.NET работният процес сериализира сесийните обектите в края на всяка заявка. При следваща заявка данните се извличат от State сървъра като двоични потоци, десериализират се и се поставят в нова колекция, вече готови за употреба. По този начин може да се реализира запазване на състоянието при срив на работния процес. А допълнително може паралелно да работят няколко процеса, което прави този подход по-скалируем.

Структура на състоянието на сесия

Класът, имплементиращ поддръжката на сесийни данни е HTTP модула SessionStateModule. Той генерира и извлича уникални идентификатори на сесията и си взаимодейства с доставчика на услуга по съхранение на данните за сесията.

Подобно на HttpApplicationState, класът SessionState предоставя две колекции Contents и StaticObjects. Работата с тях е аналогична на тази на HttpApplicationState. Ще дадем кратки примери:

Session["AppStartTime"] = DateTime.Now;

Session.Contents["AppStartTime"] = DateTime.Now;

Ето как указваме обхват "Session" на променлива в Global.asax файла:

<OBJECT RUNAT="SERVER" SCOPE="SESSION"

ID="MyInfo" PROGID="Scripting.Dictionary">

</OBJECT>

Конфигуриране на състоянието на сесия

Както споменахме, в ASP.NET може да избираме между три режима на съхраняване на данни за сесии: in-process, State Server, и SQL Server. Независимо на кой механизъм се спрем, конфигурирането на състоянието на сесиите протича в две фази. Първо, модулът за състояние се добавя към HTTP заявката. По подразбиране, тази настройка се задава на ниво компютър във файла Machine.config. Ето примерна секция от този файл:

<add name="sessionState" type="System.Web.SessionState.SessionStateModule, Version=1.0.3300.0,Culture=neutral,

PublicKeyToken=b77a5c561934e089" />

</httpmodules>

Втората стъпка е да укажем желаните атрибути за конфигурация чрез атрибута <sessionState>. Сред по-важните настройки са:

- mode - режим ("Inproc", "StateServer" или "SQLServer").

- cookieless – дали да се използват бисквитки.

- timeout – таймаут за изтичане на сесия.

Валидация на данни

Всяко едно интерактивно приложение, позволява на потребителите си да въвеждат данни. Често се случва по невнимание или преднамерено да бъдат въведени грешни данни. Ако не се обработят такива неочаквани ситуации, те могат да доведат до неочаквано поведение на приложението и дори до сриване на цялата система. Когато се очаква въведените данни да са от определен тип (примерно целочислен, реален и т.н.), в определен интервал (примерно от 0 до 100) или да отговарят на по-сложни правила (примерно да са валиден e-mail), разработчикът е длъжен да подсигури, че въведените от потребителя данни отговарят на тези изисквания.

Процесът на проверка на въведените данни наричаме валидация на данните.

Уеб приложенията, разработени с ASP.NET уеб форми, предоставят възможност за интерактивна работа на потребителя. Въведените от потребителя данни се проверяват и ако не отговарят на очакваните от приложението, уеб формата не позволява преминаване към друга форма, докато данните не бъдат коригирани.

За да се реализира ефективна валидация на данните, ASP.NET ни предоставя набор от контроли наречени валидатори. Те в значителна степен улесняват извършването на проверките.

RequiredFieldValidator – проверка за наличие на данни

Контролата RequiredFieldValidator проверява дали потребителят е въвел изобщо някакви данни. Това е един от най-често използваните в практиката валидатори.

RequiredFieldValidator – пример

Проверка дали потребителят е попълнил полето за име в дадена форма:

<asp:RequiredFieldValidator id="requiredFieldValidator"

runat="server" ErrorMessage="Name Field is required"

ControlToValidate="txtName">*</asp:RequiredFieldValidator>

Понякога ни се налага да проверим дали данните, въведени от потребителя, са различни от някаква първоначална стойност. Примерно ако използваме контролата DropDownList, в която са изброени всички държави, и като първи негов елемент стои "Select your country", естествено е да не искаме да позволим на потребителя да избере служебния запис. Тук пак може да използваме RequiredFieldValidator, като само трябва да укажем първоначална стойност в свойството InitialValue.

RequiredFieldValidator – още един пример

Ето как се използва валидаторът в този случай:

<asp:DropDownList id="ddlCountries" runat="server">

<asp:ListItem Value="0">Select your country</asp:ListItem>

<asp:ListItem Value="1">Bulgaria</asp:ListItem>

<asp:ListItem Value="2">USA</asp:ListItem>

<asp:ListItem Value="3">United Kingdom</asp:ListItem>

</asp:DropDownList>

<asp:RequiredFieldValidator id="rfvCountry" runat="server" ErrorMessage="Please select your country"

InitialValue="0" ControlToValidate="ddlCountries"> *

</asp:RequiredFieldValidator>

CompareValidator – проверка на входните данни

CompareValidator е валидатор, полезен в случаите, когато искаме:

- да сравним входните данни на една контрола с тези на друг;

- да сравним входните данни с константна стойност

- да установим дали въведените данни са от определен тип.

Ако искаме да сравним данните в две контроли (примерно две TextBox контроли), първо трябва да укажем на валидатора коя е базовата контрола (ControlToCompare) и коя е валидираната (ControlToValidate). За да се определи какво точно сравнение да се извърши (равенство, по-голямо, по-малко, по-голямо или равно, по-малко или равно или различно), се използва свойството Operator, което има стойности – Equal, GreaterThan, GreaterThanEqual, LessThan, LessThanEqual, NotEqual. Допълнително чрез свойството Type на валидатора, може да се укаже и типът на данните, които очакваме да бъдат попълнени от потребителя. Валидните типове са String, Integer, Double, Date, Currency. Стойността по подразбиране е String. Ако сме задали друга, преди да се извърши сравнение между стойностите на зададените контроли, се проверява дали стойността на контролата ControlToValidate е от съответния тип. В случай че не е, проверката за валидност връща отрицателен резултат. Ако стойността на контролата ControlToCompare, не е от зададения тип, а тази в ControlToValidate е очакваната, то проверката минава. Затова трябва да се прави изрична валидация за типа на данните в контролата ControlToCompare. Друга особеност на CompareValidator е, че ако няма въведена стойност в една от двете контроли ControlToValidate и ControlToCompare, проверката минава. Поради това се налага винаги да се използва в комбинация с RequiredFieldValidator.

В случай, че не е зададено свойството ControlToCompare, а ValueToCompare, сравнението е със стойността във ValueToCompare. Ако тя не е от указания тип в свойството Type, се хвърля HttpException. В случай, че са зададени и ControlToCompare и ValueToCompare, с приоритет е ControlToCompare.

Ако искаме само да проверим дали стойността на контролата ControlToValidate е от зададения тип, задаваме на свойството Operator, стойност DataTypeCheck.

CompareValidator – примери

Проверка дали стойностите на две текстови полета съдържат еднакви стойности:

<asp:CompareValidator id="compareValidator" runat="server"

ErrorMessage="The two fields do not match" ControlToValidate="TextBox1" ControlToCompare="TextBox2" Type="String" Operator="Equal"> </asp:CompareValidator>

Проверка дали стойността на едно текстово съвпада с низа "Бай Киро":

<asp:CompareValidator id="compareValidator" runat="server"

ErrorMessage="The value is not 'Бай Киро'" ControlToValidate="TextBox1" ValueToCompare="Бай Киро" Type="String" Operator="Equal"> </asp:CompareValidator>

Проверка дали стойността на едно поле е от целочислен тип:

<asp:CompareValidator id="compareValidator" runat="server"

ErrorMessage="You have to enter an integer value" ControlToValidate="TextBox1" Type="Integer" Operator="DataTypeCheck" /> </asp:CompareValidator>

RangeValidator – проверка попадане в интервал

Често на уеб разработчиците им се налага да осигурят, че данните, въведени от потребителя, са в определен интервал (примерно, че попадат в период ограничен от две дати или са между две числени стойности). За тази цел може да използваме контролата RangeValidator, която има много общи свойства с CompareValidator. Разликата е, че при нея трябва да укажем граници за стойностите в контролата: минимална - MinimumValue и максимална – MaximumValue. Както при CompareValidator, ако има несъответствие на въведените данни и свойството Type, възниква HttpException. Ако в контролата ControlToValidate не са въведени данни, проверката минава успешно. Затова често се налага да се комбинира с RequiredFieldValidator.

RangeValidator – пример

Проверка за дата от 2006 година:

<asp:RangeValidator

id="rangeValDate"

Type="Date"

ControlToValidate="txtDate"

MaximumValue="2006/12/31"

MinimumValue="2006/1/1"

runat="server"/>

RegularExpressionValidator – сравняване с регулярен израз

Валидация на входни данни чрез регулярни изрази е описана в детайли в едноименната тема. ASP.NET предоставя контрола RegularExpression Validator за позитивна валидация на въведените от потребителя данни. Трябва да се укажат контролата, която ще бъде валидирана - ControlToValidate, и регулярният израз, с който да се извърши проверката - ValidationExpression. Валидацията може да се извърши както при клиента, така и на сървъра. При проверка при клиента, се използват регулярните изрази в JavaScript, чиито синтаксис е подмножество на синтаксиса, поддържан от класа Regex. Препоръчително е при задаване на ValidationExpression да се използва синтаксиса на JScript регулярните изрази, за да се избегнат несъответствия. Както при предходно изброените валидатори, така и при този, ако в контролата ControlToValidate, не са въведени данни, проверката минава успешно.

RegularExpressionValidator – пример

Проверка на валиден e-mail адрес (това е опростен пример, регулярният израз, който е обхваща всички валидни адреси е значително по-голям):

<asp:RegularExpressionValidator id="revEmail" runat="server" ErrorMessage="Email is not valid." ControlToValidate="txtEmail"

ValidationExpression=

"\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*"> ! </asp:RegularExpressionValidator>

CustomValidator – произволна проверка

Описаните по-горе контроли покриват голяма част от реалните нужди на разработчика за валидация на данните. Когато са налага прилагане на по-сложна логика за валидиране на данните можем да използваме контролата CustomValidator.

Важна характеристика на валидаторите е, че валидацията винаги се извършва и на сървъра, дори да се е извършила на клиента. В досега изброените до момента контроли, това става автоматично, но при CustomValidator се налага сами да добавим тези функции. Това става с прихващане в уеб формата на събитието ServerValidate, което е с аргумент обект от тип ServerValidateEventArgs. За целта са ни нужни стойността на контролата, която се валидира, и променлива, в която да върнем резултата. Аргументът от тип ServerValidateEventArgs, подаден от събитието, съдържа стойността на валидираната контрола ControlToValidate в свойството Value. След извършване на проверката, трябва да върнем резултат чрез свойството IsValid.

CustomValidator – пример

За да илюстрираме употребата на CustomValidator контрола, нека разгледаме форма със следното съдържание: два бутона за алтернативен избор (RadioButton), чрез които потребителят указва своя пол (мъж / жена), и едно текстово поле, в което той попълва своя ЕГН. ЕГН е десетцифрен номер, в който първите шест цифри са за рождената дата, седмата и осмата са за служебна информация за район, деветата е за пола, а десетата цифра е контролна. Алгоритъмът на пресмятане на десетата цифра е известен, но сега няма да го дискутираме.] Искаме да сверим дали дадено ЕГН, съответства на избрания пол. Ако един човек е мъж, деветата цифра е четна, ако е жена – нечетна. На тази база ще изградим валидация чрез контролата CustomValidator. Частта от уеб формата, която ни интересува, е:

<asp:RadioButton ID="rbtnFemale" Runat="server"

Text="Жена" Checked="True" GroupName="Gender" />

<asp:RadioButton ID="rbtnMale" Runat="server"

Text="Mъж" GroupName="Gender" />

<asp:TextBox id="txtEGN" runat="server" />

<asp:CustomValidator id="cvEGN" Runat="server"

ErrorMessage="Въвели сте невалиден ЕГН"

EnableClientScript="True"

ControlToValidate="txtEGN"

ClientValidationFunction="ValidateEGN">*</asp:CustomValidator>

Освен стандартния атрибут ControlToValidate на CustomValidator контролата сме задали и атрибута ClientValidationFunction. В него се задава името на JavaScript функцията, отговаряща за валидацията при клиента. В кода зад формата се абонираме за събитието ServerValidate:

cvEGN.ServerValidate +=

new ServerValidateEventHandler(cvEGN_ServerValidate);

Функцията cvEGN_ServerValidate(…) реализира валидацията на сървъра:

private void cvEGN_ServerValidate(object source, ServerValidateEventArgs args)

{

string pattern = @"^[0-9]{10}$";

if( Regex.IsMatch(args.Value, pattern) )

{

int genderDigit =

Convert.ToInt32( args.Value.Substring(8,1) );

if( (genderDigit % 2) == 0 )

{

if( rbtnMale.Checked )

{

args.IsValid =true;

}

else

{

args.IsValid = false;

}

else

{

if( rbtnFemale.Checked )

{

args.IsValid =true;

}

else

{

args.IsValid = false;

}

else

{

args.IsValid = false;

}

Тази функция използва елементарен регулярен израз, за да провери дали потребителят е въвел смислени данни. Функцията, която отговаря за валидацията при клиента, се реализира на език, поддържан от браузърите (най-често се използва JavaScript и VBScript). Ето функцията ValidateEGN(…) на JavaScript:

function ValidateEGN( source, arguments )

{

var pattern = /^[0-9]{10}$/;

var rbtnMale = document.getElementById("rbtnMale");

var rbtnFemale = document.getElementById("rbtnFemale");

if ( pattern.test(arguments.Value) )

{

var genderDigit = arguments.Value.substr(8,1) ;

if( (genderDigit % 2) == 0 )

{

if( rbtnMale.checked )

{

arguments.IsValid =true;

}

else

{

arguments.IsValid = false;

}

else

{

if( rbtnFemale.checked )

{

arguments.IsValid =true;

}

else

{

arguments.IsValid = false;

}

else

{

arguments.IsValid = false;

}

</script>

ValidationSummary – списък на грешките

Когато потребителите попълват форми, могат да въведат грешни данни в повече от една контрола. В такива случаи е най-удобно да се изкара списък (резюме) на грешките и за целта ASP.NET ни предоставя контрола ValidationSummary. При извършване на валидация всеки валидатор проверява дали са въведени коректни данни и ако не са, в контрола ValidationSummary се извеждат съобщенията за грешка, зададени чрез атрибута ErrorMessage.

Контролата ValidationSummary предлага следните опции:

- Свойството DisplayMode определя по какъв начин да се покажат грешките. Възможните стойности за него са – BulletList, List, SingleParagraph. Стойността по подразбиране е BulletList.

- Свойството EnableClientScript определя дали при клиента да се изпълни скрипт и да се избегне ходене до сървъра, или списъкът с грешките да се попълни чак на сървъра. Стойността по подразбиране е true.

- Свойството ShowSummary определя дали списъкът с грешки да се показва на потребителя. Стойността по подразбиране е true.

- Свойството ShowMessageBox определя дали да се покаже на потребителя списъкът с грешки под формата на MessageBox. Ако стойността на този атрибут е true, за да се покаже MessageBox, е необходимо и стойността на EnableClientScript да е true. Стойността по подразбиране е false.

- Свойството HeaderText определя какво да е заглавието на резюмето с грешки. Стойността по подразбиране е празният низ.

Йерархия на класовете валидатори

Следната клас диаграма описва йерархията на валидаторите:

Валидаторите се явяват специализирани Label контроли. Базовият клас BaseValidator дефинира общите за всички валидатори свойства – ControlToValidate, Display, EnableClientScript, Enabled, ErrorMessage, IsValid. RangeValidator и CompareValidator наследяват от BaseCompareValidator общото свойство Type.

Общи свойства за валидаторите

Като наследници на базовия клас BaseValidator, всички валидатори имат някои общи свойства:

- ControlToValidate – задава на коя контрола да бъдат проверени входните данни.

- Display – контролира по какъв начин да се показва текста на валидатора (става дума за стойността на свойството Text, а не за стойността на свойството ErrorMessage). Възможните стойности за този атрибут са – Dynamic, Static, None. Стойността по подразбиране е Static. При None не се показва нищо. Разликата между Dynamic и Static е малка и е свързана с факта, че валидаторите се визуализират (render) като <span> тагове. Когато Display има стойност Dynamic, атрибутът style на <span> тага изглежда така: style="color:Red; display:none;". Докато при Static, атрибутът style на <span> тага изглежда така: style="color:Red; visibility:hidden;". Разликата е в това, че пространството, заето от текста на валидатора при стойност Static, е предварително заделено, докато при Dynamic се заделя при появата на текста.

- EnableClientScript – указва дали валидацията за дадения валидатор ще се извърши и при клиента, или само на сървъра. Приема стойности true и false ( по подразбиране - true). Всеки един от валидаторите с изключение на CustomValidator има реализация на проверката за валидност при клиента. Ако стойността на EnableClientScript е true, при клиента се прави проверка, като в случай на невалидни данни се спестява ходенето до сървъра.

- Enabled – контролира дали съответният валидатор е активен или не. Стойността по подразбиране е true.

- ErrorMessage – съхранява съобщението за грешка, което се показва на потребителя при въведени некоректни данни.

- IsValid – показва дали съответният валидатор е минал успешно проверката на данните. Стойността на това поле по подразбиране е true.

Кога и къде се извършва валидацията?

Когато използваме стандартните валидатори на ASP.NET, проверката за валидност се извършва винаги на сървъра. В зависимост от стойността на полето EnableClientScript може да има проверка и при клиента, но задължително се проверява и на сървъра.

При проверката за валидността на данните, се задава булева стойност на свойството IsValid на уеб формата, в зависимост дали проверката е минала успешно или не. Тази стойност се задава автоматично от метода на формата Validate(), който се извиква по време на изпълнението на уеб формата. За да разчитаме, че полето IsValid съдържа коректна стойност, трябва да знаем в кой етап от модела на изпълнение на формата се извиква този метод. Честа грешка в практиката е да се проверява дали формата е валидна при събитието Load на формата. Това е погрешно, защото методът Validate() се извиква след събитието Load и преди събитията, свързани с останалите контроли на формата (Click, SelectionChange и други).

Има случаи, в които не искаме да се проверяват за валидност въведените от потребителя данни. Най-тривиалният пример е с форма, в която потребителят трябва да въведе някакви данни и да потвърди с бутона Submit, но да може и да се откаже с бутона Cancel. В този случай трябва при натискане на Submit да се извърши валидация, а при натискане на Cancel да не се прави такава. За целта на атрибута CausesValidation на бутона Cancel се задава стойност false.

Защо винаги на сървъра?

Валидацията при клиента става чрез скриптове, изпълнявани на машината на потребителя. Потребителите могат да вдигнат нивото на сигурност и изцяло да забранят изпълнението на скриптове.

Скриптовете за валидация са базирани на така наречения Document Object Model. При различните браузъри (Internet Explorer, Firefox, Netscape, Opera…) и дори при различните версии на един браузър този модел е реализиран по различен начин, въпреки утвърдените общи стандарти. В резултат на това валидацията при различните браузъри може да даде различни резултати.

Допълнително трябва да се има предвид, че скриптовете са просто обикновен текст, интерпретиран от браузъра на клиента. Потребителят има пълната свобода да редактира скрипта и да го накара да прави това, което той пожелае.

Тези факти около сигурността и консистентността на скриптовете са причината проверката за валидност на данните винаги да се прави на сървъра.

Особености при валидацията при клиента

Валидацията при ASP.NET 1.1 има някои особености. Тя има едно важно ограничение:

Валидацията, реализирана чрез стандартните валидатори на ASP.NET 1.1, работи само с Internet Explorer.

За да извърши валидация, ASP.NET рендира допълнителен скрипт на JavaScript, който е съвместим само с Internet Explorer. За да се извърши проверка за всички валидатори при клиента, те се поставят в JavaScript масив и след това един по един проверяват дали потребителят е въвел коректни данни. Частта от скрипта, която се поддържа само от Internet Explorer е:

document.all["validator_name"]

Така, ако уеб формата има четири RequiredFieldValidator контроли, JavaScript кодът изглежда по следния начин:

var Page_Validators = new Array(

document.all["RequiredFieldValidator1"],

document.all["RequiredFieldValidator2"],

document.all["RequiredFieldValidator3"],

document.all["RequiredFieldValidator4"]);

Проблемът може да бъде избегнат и в ASP.NET 1.1, но за целта трябва програмиста да реализира свои контроли за валидатори. В следващата версия на ASP.NET (2.0) този проблем е решен и валидацията при клиента работи с всички уеб браузъри.

Потребителски контроли

HTML и уеб сървър контролите предлагат лесен начин за повторно използване (reuse) на функционалност. Но често се налага на няколко места да искаме да използваме комбинация от група контроли, които да имат еднакъв вид и/или поведение. За целта ASP.NET предлага възможност за разработка на потребителски контроли (user controls). Те предоставят удобен начин за споделяне на функционалност и потребителски интерфейс между страниците на приложението.

Потребителски контроли и уеб форми

Потребителската контрола е елемент подобен на ASP.NET уеб форма, който може да се вгражда в други ASP.NET уеб форми. Подобно на уеб формите, потребителските контроли са сървърни компоненти, които предлагат потребителски интерфейс и функционалност.

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

Потребителските контроли са наследници на System.Web.UI.UserControl в обектния модел на ASP.NET. Те се описват във файл с разширение (.ascx).

Предимства при използването на потребителски контроли

- Самостоятелни – потребителските контроли са самостоятелни и предоставят отделни пространства от имена (namespaces) за променливите. Така не се получават колизии със съществуващи методи и свойства на страницата, която ползва потребителската контрола.

- Преизползваеми (reusable) – потребителските контроли могат да се използват повече от веднъж на една или няколко страници.

- Езиково неутрални – потребителските контроли могат да бъдат писани на различен програмен език от използвания в страницата, в която се разполагат.

Споделяне на потребителски контроли

Потребителските контроли могат да се споделят между всички страници на уеб приложението, но много трудно се споделят между различни уеб приложения. Ако искаме по-широко преизползване без copy&paste, трябва да разработваме Web custom контроли, чието създаването е много по-трудоемко.

Използване на потребителски контроли

Потребителската контрола може да се постави във всяка ASP.NET уеб форма. Формата, която добавя контролата, се нарича домакин (host). Формата добавя контролата, като използва директивата @Register.

Примерно използване:

<%@ Register TagPrefix="demo" TagName="validNum" Src="numberbox.ascx" %>

Атрибутът TagPrefix указва уникално пространство от имена за потребителската контрола, за да няма колизии, ако същата контрола се използва повторно. Атрибутът TagName e име на инстанцията на контролата. Атрибутът Src е релативен път до файла на контролата.

Създаване на потребителска контрола – пример

В този пример ще създадем потребителска контрола, която служи за меню. Менюто в един сайт би трябвало да присъства на всяка страница от сайта и затова е подходящо да го направим потребителска контрола. Така на всяка страница ще добавяме само меню контролата, вместо да създаваме меню от нулата.

Нека първо създадем три уеб форми – за начална страница (Main), за страница с контакти (Contacts) и за страница с информация (About).

<%@ Page language="c#" Codebehind="MainForm.aspx.cs"

AutoEventWireup="false"

Inherits="Demo_4_WebUserControl.WebForm1" %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >

<HTML>

<HEAD>

<title>WebForm1</title>

</HEAD>

<asp:Label id="LabelMain" style="Z-INDEX: 101; LEFT: 136px; POSITION: absolute; TOP: 16px" runat="server">Main Page </asp:Label>

</form>

</body>

</HTML>

Както виждате на нея има само един етикет отбелязващ името на страницата (Main, Contacts, About).

Ще се заемем с направата на потребителската контрола:

Въвеждаме име за контролата:

Получаваме файл с разширение ascx, в който има първоначално следният код:

<%@ Control Language="c#" AutoEventWireup="false"

Codebehind="MenuWebUserControl.ascx.cs"

Inherits="Demo_5_WebUserControl.MenuWebUserControl"

TargetSchema="http://schemas.microsoft.com/intellisense/ie5"%>

За да се появят бутони в менюто, добавяме следния код за три уеб контроли за бутони:

<p>

<asp:HyperLink id="LinkMain" runat="server"

NavigateUrl="MainForm.aspx">Main</asp:HyperLink>

<br/>

<asp:HyperLink id="LinkContacts" runat="server"

NavigateUrl="ContactsForm.aspx">Contacts</asp:HyperLink>

<br/>

<asp:HyperLink id="LinkAbout" runat="server"

NavigateUrl="AboutForm.aspx">About</asp:HyperLink>

</p>

Всеки бутон води до една от трите уеб форми, които създадохме. Следващата стъпка е да добавим новата контрола към всяка от трите уеб форми. Ето как изглеждат новополучените уеб форми:

Сега ни остава само да пуснем приложението и да проверим какво сме направили:

Всичко работи както трябва – менюто ни пренасочва към отделните страници.

Забележка: Контролите могат да се зареждат динамично с LoadControl() метода. Не е задължително да ги декларираме в .aspx страницата.

Проследяване и дебъгване на уеб приложния

За диагностициране на проблеми в уеб приложенията се използват две основни техники – проследяване (tracing) и дебъгване (debugging).

Информация по време на изпълнение

Докато уеб приложението работи, можете да събирате информация като използвате класовете Trace и Debug. Възможно е да извършвате следните действия по време на работа на приложението:

- да изписвате стойности на променливи;

- да разберете дали определени изисквания са изпълнени. Например методът Trace.WriteIf(…) изписва съобщение само когато е изпълнено дадено условие;

- да проследявате пътя на изпълнение на приложението. Можете да следвате програмната логика на дадена уеб форма, докато приложението се изпълнява, за да проверите дали всичко се извършва както очаквате.

Проследяване

Класовете Trace и Debug от пространството от имена System.Diagnostics са стандартния механизъм в .NET Framework за изписване (показване) на информация по време на изпълнение (runtime).

С Trace информацията се показва на самата уеб страница или се запазва в паметта. За да се следи състоянието на уеб приложението в традиционните ASP страници можеше да се използват методите Response.Write или изписване на debug информация в Label контроли на уеб формата. Предимството на Trace пред тези подходи е, че проследяването може да се контролира централизирано чрез настройките в конфигурационния файл Web.config. Така след като свършите с дебъгването на приложението си, можете лесно да изключите показването на информацията.

Методите на класа Debug, ще се изпълнят само ако приложението е компилирано в дебъг режим и е стартирано в дебъгер. Когато създавате release версия, извикванията няма да се изпълнят. С класа Debug можете да изписвате съобщения в Output прозореца на дебъгера на Visual Studio .NET. Използването на класа Debug не намалява надеждността на приложението, защото кодът не се променя - в release режим тези оператори просто не се изпълняват.

Проследяване на ниво страница и приложение

Проследяването може да ви помогне да диагностирате проблеми и да анализирате производителността. Можете да пишете директно в страницата или да запазвате trace информацията в база от данни.

При проследяване на ниво страница (page-level tracing), съобщенията се добавят в края на уеб страницата, за която е пуснато проследяването. При проследяване на ниво приложение (application-level tracing) съобщенията се добавят към всяка страница в приложението.

Използването на проследяване, пуснато само за отделна страница, позволява бързо да се види информацията от проследяването, докато се разглежда съдържанието на страницата. Когато стане ненужно, то може директно да бъде изключено, без да премахвате всички Trace.Write(…) оператори от кода.

Проследяването на ниво приложение (application-level tracing) се контролира от Web.config файла и дава повече гъвкавост. Например може съобщенията от проследяването да се пазят в паметта, и по-късно да се показват чрез използването на специалната страница trace.axd.

Категории на проследяване

Има няколко категории от информация, които се показват в Trace:

- Request Details - информация за заявката: идентификатор на сесията (ID), време на заявката, вид на заявката и статус на заявката;

- Trace Information - изход (Output) от стандартни и потребителски дефинирани trace оператори. Колоната "From First(s)" указва времето в секунди, откакто първото съобщение в тази секция е било показано. Колоната "From Last(s)" указва времето, изминало от показването на предишния ред. За яснота: за всеки два последователни записа (реда) имаме: From First(s) - From Last(s) на втория е равно на From First(s) на първия;

- Control Tree - списък на всички елементи, които са на страницата, с големината на всеки от тях;

- Cookies Collection - списък на всички използвани бисквитки (cookies);

- Headers Collection - списък на всички записи в HTTP хедъра;

- Form Collection - списък на контролите и техните стойности във формата (<form runat="server">...);

- Server Variables - списък на всички сървърни променливи: името на сървъра, текущо изпълняваната .aspx страница и т.н.

Обектът Trace

Освен класа System.Diagnostics.Trace, съществува и едноименно свойство на страницата Trace, което е от тип TraceContext. С негова помощ в секцията "Trace Information" освен показването на стандартна (предефинирана) информация от проследяването, можете да изписвате и произволни съобщения в определени от вас категории. Използват се методите Trace.Write(…) и Trace.Warn(…), които работят по подобен начин, с единствената разлика, че Trace.Warn(…) изписва съобщенията в червено.

Динамичен контрол върху проследяването

Със свойството Trace.IsEnabled проследяването може динамично да се включва/изключва. Свойството е с по-голям приоритет от настройките за проследяване на ниво приложение.

Настройки на проследяването

Дори когато бъде пуснато проследяване на ниво приложение, настройките за проследяването на ниво страница се запазват. Например, ако се изключи проследяване за някоя страница, а проследяването за цялото приложение е пуснато, за страницата няма да се появи проследяваща информация. Следната таблица показва резултатите от различните комбинации проследяване на ниво приложение и на ниво страница:

На ниво страница	На ниво приложение	Резултат за конкретната страница
Trace=True	без значение	има проследяване (trace)
Trace=False	без значение	няма проследяване (trace)
не е указано	Trace=True	има проследяване (trace)
не е указано	Trace=False	няма проследяване (trace)

Атрибутът pageOutput

За указване къде да се показват съобщенията от проследяването можем да се използваме атрибута pageOutput на елемента trace във файла Web.config. Ако е true, съобщенията се показват на самата страница след края на съдържанието й (добавят се отдолу). Ако е false, съобщенията се записват в паметта. Ето един пример за изключване на съобщенията от страницата (запазват се в паметта):

<system.web>

</system.web>

</asp:DropDownList>

Страницата trace.axd

Ако информацията от проследяването не се показва на страницата, тя се запазва в паметта. Може да бъде видяна, като се използва специална страница, която е включена по подразбиране във всяко уеб приложение. Адресът на страницата е: http://сървър/проект/trace.axd.

Поради причини свързани със сигурността, тази страница понякога е добра да бъде спряна. Това може да стане на ниво уеб сървър чрез конфигурационния файл machine.config. Той се намира в системната папка C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG, като някои от директориите може да са с различни имена:

<add verb="*" path="trace.axd"

type="System.Web.Handlers.TraceHandler">

</httpHandlers>

В горния пример, за да бъде спряна страницата, трябва атрибутът path да има за стойност празен текст (path="").

Проследяване в потребителски компонент

Ако един компонент се вика от уеб форма, в него могат да се използват методите за проследяване (като Trace.Write(…) и Trace.Warn(…)). Това позволява да се генерират съобщения за проследяване (trace messages) за уеб формата и за компонента.

Когато се позволи проследяване в компонент, съобщенията се изписват в резултатите на всяка страница, която ползва компонента дори ако проследяването за тази страница е спряно.

Отдалечено дебъгване

Под отдалечено дебъгване (remote debugging) се разбира дебъгване на приложения на отдалечен сървър. Можете да дебъгвате от една работна станция ASP.NET приложения, изпълнявани на множество сървъри.

За отдалеченото дебъгване се изискват:

- Visual Studio .NET или неговите компоненти за отдалечено ползване, инсталирани на сървъра.

- Visual Studio .NET, инсталирано на работната станция.

- Административни права за сървъра.

- Акаунтът, използван за сървъра, да е в групата Debugger Users.

Стъпки за отдалечено дебъгване:

1. Стартира се Visual Studio .NET на клиентската машина.

2. File à Open à Project From Web.

3. В Open Project From Web диалоговата кутийка се пише адреса (URL) на сървъра.

4. В Open Project диалоговата кутийка се избира проектът на отдалечения сървър.

5. След като се отвори проектът, може да се използват breakpoints все едно приложението е локално.

Оптимизация, конфигурация и разгръщане на ASP.NET приложения

До момента разгледахме основните концепции и техники за разработка на ASP.NET уеб приложения. Сега, нека обърнем внимание на средствата за оптимизиране на уеб приложения чрез кеширане и на процеса на разгръщане на уеб приложение в средата, където трябва да работи (deployment), както и свързаните с това настройки на конфигурационни файлове.

Оптимизиране чрез кеширане

При изграждането на големи уеб приложения, които ще бъдат използвани едновременно от много потребители в рамките на минути или секунди, ние ще повтаряме едни и същи операции за всяка индивидуална заявка към нашето приложение. За да избегнем този повтарящ се процес, може да използваме кеширане. Кеширането е процес на запазване на често достъпвани данни (или такива, чието извличане отнема много ресурси) в паметта (или друго хранилище). Така те могат лесно и бързо да бъдат извлечени при повторно поискване.

Кеширане в ASP.NET

Кеширането е една от най-често използваните техники за оптимизация на ASP.NET приложение. В ASP.NET има два вида кеширане. Първият е кеширане на цялата aspx страница (генерирания HTML код) или части от нея. Вторият е кеширане на специфична за приложението информация, която ще бъде повторно достъпна за разработчика.

Кеширане на страница или отделни фрагменти от нея

Кеширането на ASP.NET страница се изразява в запазване на HTML кода, който тя е генерирала за определен период от време. При повторно извикване на същата страница, преди този период да е изтекъл, към клиентския браузър се изпраща вече генерирания HTML. Този процес значително подобрява бързодействието на приложението, като дори задаване на период от няколко секунди може да даде видим резултат.

За да укажем, че искаме дадена страница да се кешира, трябва да използваме директивата @OutputCache. Ето и пример, който указва, че дадената страница (или контрола) трябва да се кешира за 30 секунди:

<%@ OutputCache Duration="30" VaryByParam="None" %>

Същият резултат може да постигнем и в кода, който стои зад страницата. Ето пример как можем да направим това:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(30));

Response.Cache.SetCacheability(HttpCacheability.Server);

Няма да се впускаме в подробности за разликата между двата начина, само ще споменем, че чрез методите на HttpCachePolicy (инстанция на този тип се връща от свойството Cache на Response) имаме достъп на ниско ниво до различните опции за кеширане. Докато чрез директивата OutputCache ни се предоставя едно добро ниво на абстракция, като ясно декларираме какво точно да се кешира.

Нека да разгледаме по-важните атрибути на директивата @OutputCache:

Атрибут	Описание
Duration	Време за кеширане Указва времето в секунди, за което дадената страница (потребителска контрола) ще се кешира. Атрибутът е задължителен.
VaryByParam	Кеширане на версии по параметър Чрез този атрибут може да кешираме няколко различни версии на страницата. Той ни позволява да зададем списък от параметри, разделени с точка и запетая, спрямо които да се кешират различните версии, понеже съдържанието на страницата (рендираният HTML) може да е различно спрямо даден параметър от query string, Атрибутът е задължителен. Негови стойности може да са * и None.
VaryByControl	Кеширане на версии по ID на контрола Атрибутът е подобен на предходния с изключение, че като стойност се задават ID на потребителските контроли, които искаме да кешираме.
Shared	Кеширане между отделни страници Този атрибут се указва само в потребителски контроли. Неговото предназначение е да укаже дали кешираната контрола може да се използва между отделните страници на приложението. Използва се при статични потребителски контроли, например лого или банер.

Кеширане на данни

Досега разгледаният метод за кеширане беше на ниво страници и генерирани от тях HTML. Сега ще разгледаме другия вид за кеширане в ASP.NET, а именно кеширането на информация (обекти), която да бъде лесно достъпна при повторно поискване. Това е възможно благодарение на класа System.Web.Caching.Cache, който служи като контейнер (речникова колекция) за обекти, които ще бъдат използвани повторно. Нека да разгледаме някои от предимствата и недостатъците на Cache класа, след което ще се спрем на различните начини за добавяне на обекти в кеша и тяхното унищожаване (invalidation).

Предимства:

- Осигурява бърз достъп до обекти, чието създаване е бавно, скъпо или отнемащо много ресурси (извличане от база данни, уеб услуга, криптирано устройство и др.).

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

- Предлага разнообразни опции за унищожаване на обектите в него (дори и за тяхното обратно създаване чрез callback функции).

- Автоматично започва да унищожава кешираните обекти, когато ресурсите на сървъра намалеят.

Недостатъци/забележки:

- Може да се използва в рамките на едно приложение, т.е. всяко едно приложение има свой кеш, който е единствен и не може да бъде споделян с останалите приложения.

- Горното ограничение ефективно води до загуба на скалируемост. Обектите са тясно свързани с приложението, работещо на конкретния сървър и не могат да бъдат споделяни между сървъри в уеб ферми.

- Cache контейнерът е активен (жив), докато приложението работи. При рестартиране на приложението Cache обектът се създава отново.

- Cache контейнерът не може да съхранява данни за конкретен потребител. За тази цел се използва сесията (HttpSessionState) или речниковата колекция HttpContext.Items, ако искаме да запазим информация само за текущата заявка.

Кеширане на данни – примери

Както вече споменахме, добавянето на обекти в кеша може да стане по няколко начина с различни политики за унищожението на добавяния обект.

Стандартният начин е да се обърнем към кеша като речникова колекция. Ето един пример:

DataSet dsUsers = GetAllUsers();

Cache["UsersDataSet"] = dsUsers;

Извличането на вече добавен обект също е стандартно:

DataSet dsUsers = (DataSet) Cache["UsersDataSet"];

Ако обектът междувременно е бил унищожен, се връща null.

Политики за унищожаване на обектите при кеширане

Да разгледаме по-подробно метода Insert(…) на Cache. Този метод има няколко дефиниции с различен брой параметри, които може да използваме, за да задаваме различни политики относно това кога да се унищожи добавяният обект. Ето примери за използването на всяка една от тях:

- Унищожаване на добавяния обект след определен период от време. Следният код добавя обект, който ще бъде унищожен след 5 минути:

Cache.Insert("myKey", myValue, null, DateTime.Now.AddMinutes(5),

Cache.NoSlidingExpiration);

- Унищожаване на добавяния обект след определен период от време от последното му използване. Следният код добавя обект, който ще бъде унищожен 20 секунди, след като е бил използван. Ако в следващите 20 секунди отново извлечем този обект от кеша, отчитането на секундите започва отначало:

Cache.Insert("myKey", myValue, null, Cache.NoAbsoluteExpiration,

TimeSpan.FromSeconds(20));

- Унищожаване на добавяния обект при дадена зависимост (промяна на файл или унищожаването на друг обект от кеша). В последните два примера третия параметър, който подаваме на метода, е CacheDependency. Чрез конструкторите на този клас можем да укажем изтриване на добавяния обект при промяна на даден файл (съвкупност от файлове) или при унищожаването на друг обект (съвкупност от обекти) от кеша.

Ето пример, който илюстрира как добавяният обект ще се унищожи, когато файлът myConfig.xml бъде променен:

Cache.Insert("myKey", myValue,

new CacheDependency(Server.MapPath("myConfig.xml")));

- Задаване на приоритет на добавяния обект. Друга възможност, която ни се предоставя, е да зададем приоритет на добавяния обект. Когато сървърът започне да освобождава ресурси, сравнява приоритетите на всички обекти и унищожава тези с най-нисък приоритет. Възможните приоритети са стойностите на изброимия тип CacheItemPriority – Low, BelowNormal, Normal (Default), AboveNormal, High, NotRemovable. В следващия пример обектът, който добавяме, ще е един от последните унищожени:

Cache.Insert("myKey", myValue, null, Cache.NoAbsoluteExpiration,

Cache.NoSlidingExpiration, CacheItemPriority.High, null);

- Извикване на callback функция, когато даден обект бива унищожен. Кеш класът ни предоставя и възможност за извикване на наша callback функция. За целта трябва да създадем инстанция на делегат от тип CacheItemRemovedCallback. Ето пример:

public void RemovedCallback(string aKey, object aValue,

CacheItemRemovedReason aCallbackReason )

{

switch ( aCallbackReason )

{

case CacheItemRemovedReason.Expired :

//do work when item is expired

break;

case CacheItemRemovedReason.DependencyChanged :

//do work when item's dependency changed

break;

default:

break;

}

private void CacheItem( string aKey, object aItem )

{

CacheItemRemovedCallback onRemove =

new CacheItemRemovedCallback(RemovedCallback);

Cache.Insert( aKey, aItem, null, Cache.NoAbsoluteExpiration,

Cache.NoSlidingExpiration, CacheItemPriority.Default,

onRemove );

}

Възможността за извикване на callback функции може да се използва и за да се постави обекта отново в кеша.

Конфигуриране на ASP.NET приложение

Конфигурацията на едно ASP.NET приложение се извършва на основата на съвкупност от няколко XML базирани конфигурационни файла. Изнасянето на конфигурационните настройки в отделен файл (а не в кода) дава изключително лесна процедура за разгръщане на приложението (XCOPY Deployment). Това позволява и промяна на някои от настройките, без да се налага прекомпилация.

Файлът Machine.config

Всеки ASP.NET уеб сървър има свой глобален конфигурационен файл – Machine.config. Той се намира в: systemroot\Microsoft.NET\ Framework\<versionNumber>\CONFIG\Machine.config, където systemroot стандартно е C:\WINDOWS, a versionNumber e v1.1.4322 за .NET Framework 1.1 В този файл се съдържат глобалните настройки (настройки по подразбиране). Те се прилагат върху всяко едно уеб приложение. Няма да се спираме подробно на тях , само ще споменем, че в Machine.config се съдържат и глобалните настройките за machineKey, Той служи за криптиране и хеширане на ViewState и бисквитката за сесията. В случай, че имаме приложение, което работи в web-farming среда (на няколко сървъра), трябва да сме подсигурим, че стойностите на machineKey на всеки един от сървърите са еднакви.

Неправилна промяна на файла Machine.config може да окаже влияние на всички уеб приложения, които работят на сървъра.

Файлът Web.config

Освен глобалния конфигурационен файл за сървъра всяко едно отделно приложение има свой собствен конфигурационен файл – Web.config. Той вече ни е познат, защото когато създадем нов уеб проект, това е един от файловете, който автоматично е добавен в него. Ето как изглежда той в редактора на Visual Studio:

Във файла Web.config се указват специфичните настройки за приложението, като някои от тях може да препокриват тези от файла Machine. config. Всички настройки са разположени йерархично в различни секции или категории. За да разберем какво точно може да конфигурираме, нека да разгледаме по-значимите от тях.

Категории в Web.config

Настройките, които можем да зададем във файла Web.config, свързани с работата на уеб приложението, се намират в секцията system.web. Ето нейните по-важните подсекции:

Секция	Описание
authentication	Избор на метод на автентикация и неговите свойства. Подробно ще се спрем на автентикация в частта "Сигурност".
authorization	Предоставя възможност за декларативно прилагане на сигурността, базирана на роли (role-based security) и оторизацията на потребителите.
browserCaps	Възможност за задаване на филтри, спрямо които браузъра, направил заявката, може да се разпознае и асоциира.
compilation	Настройки, указващи по какъв начин да се компилира приложението, когато дойде първата заявка към него.
customErrors	Възможност за конфигуриране как ASP.NET да се справя с възникналите грешки и изключения.
globalization	Настройки на глобализацията на приложението, в това число културата на приложението, кодирането на файловете, заявките и отговорите, направени от и към сървъра.
httpHandlers	Предоставя възможност за асоцииране на класове, които да обработят заявки към дадени ресурси.
httpModules	Предоставя възможност за добавяне на допълнителни модули, които да предоставят дадена функционалност. Сесията, автентикацията и оторизацията са реализирани като такива модули.
identity	Възможност за имперсонация на текущия потребител, с който се асоциират заявките към сървъра.
pages	Предоставя възможност да се променят настройките по подразбиране за всички страници в приложението.
processModel	Богат набор от настройки за изпълнението на приложението от IIS, включително дали да се използва уеб ферма.
sessionState	Разнообразни настройки за сесията – дали да се използват бисквитки, дали сесията да бъде съхранена в SQL сървър и др.
trace	Настройки за проследяването на приложението – дали да се проследява, да се показва ли дневникът (log) на страницата и др.

Забележка: Съдържанието на Web.config е чувствително към малки и главни букви.

Разширяемата структура на файла Web.config

Както вече разгледахме, файлът Web.config ни предоставя богата възможност за конфигуриране на отделните части от приложението. Но всяка разгледана до сега настройка беше стандартно предоставена от ASP.NET. Как обаче да съхраним наша специфична информация за приложението в конфигурационния файл? За тази цел може да използваме специалната секция в Web.config файла – appSettings. В нея може да задаваме двойки ключ-стойност. Те са достъпни програмно по време на изпълнение на приложението. Ето примерен конфигурационен файл:

<system.web>

...

</system.web>

<add

key="ConnectionString"

value="server=demoserver;database=pubs;uid=sa;pwd=" />

<add

key="MailServer"

value="DemoHost" />

</appSettings>

</configuration>

Извличането на тези стойности става по следния начин:

string connectionString = System.Configuration.

ConfigurationSettings.AppSettings["ConnectionString"];

SqlConnection conn = new SqlConnection(connectionString);

. . .

SmtpMail.SmtpServer = System.Configuration.

ConfigurationSettings.AppSettings["MailServer"];

ASP.NET ни дава възможност да изграждаме наши собствени конфигурационни секции в файла Web.config. Чрез тях можем да структурираме конфигурационните настройки на приложението и да групираме в отделни блокове логически свързаните.

Йерархия на конфигурационните файлове

Всяка директория в уеб приложение може да съдържа свой собствен конфигурационен файл (Web.config), в който може да се предефинират настройките за тази директория и всички нейни поддиректории. По този начин се получава йерархия на конфигурационните настройки и файлове. Най-отгоре стои глобалният конфигурационен файл за сървъра - Machine.config. Неговите настройки се наследяват от главния конфигурационен файл за приложението (файла Web.config, разположен в главната директория). Те се прилагат върху всички поддиректории.

Разгръщане на приложението

След като вече разгледахме какви са възможностите за конфигуриране на приложението, сега ще спрем вниманието си върху неговото разгръщане (deployment) и последващата го поддръжка и обновяване. Но малко преди това ще проследим стъпките за инсталиране и конфигуриране на уеб сървъра.

Инсталиране и конфигуриране на уеб сървъра

Уеб сървърът (IIS – Internet Information Services) не е инсталиран стандартно в Windows 2000 или Windows XP (нещата не стоят така при Windows Server 2000 и 2003). За да го инсталираме, трябва да направим следното.

1. Отваряме Control Panel и избираме Add or Remove Programs.

2. От появилия се прозорец избираме етикета Add/Remove Windows Components.

3. От новопоявилия се списък с компоненти на операционната система избираме и инсталираме Internet Information Services (IIS).

Ако успешно сме извършили гореописаната операция, ще трябва да рестартираме Windows. След рестартиране, от Control Panel -> Administrative Tools -> Internet Information Services можем да отворим интерфейса за конфигуриране на сървъра.

В случай, че сме инсталирали Visual Studio .NET преди IIS (или изобщо нямаме Visual Studio), ще е необходимо да регистрираме ASP.NET работния процес. За целта трябва да въведем следния ред в командния интерпретатор на Visual Studio, намиращ се в неговото подменю в Start менюто:

aspnet_regiis –i

Това може да стане и като стартираме файла aspnet_regiis.exe, който се намира в systemroot\Microsoft.NET\Framework\versionNumber\ с параметър –i.

Необходими файлове

Както всички .NET приложения, така и ASP.NET уеб приложенията се разгръщат чрез просто копиране (XCOPY deployment). Необходимите файлове, които трябва да копираме във виртуалната директория на приложението, са:

- папката bin, която съдържа компилираните code-behind класове и всички асемблита, които сме реферирали в нашия проект.

- всички уеб форми (*.aspx) и потребителски контроли (*.ascx)

- конфигурационните файлове на приложението (Web.config) и файла за обработка на глобални събития (Global.asax).

- всякакви други допълнителни файлове, които използва приложението – картинки, лицензни файлове и др.

- ако приложението използва динамична компилация, ще са ни нужни и code-behind файловете (*.aspx.cs и *.ascx.cs).

Всички останали файлове, които се намират в директорията на приложението, не са необходими (*.sln, *.csproj, *.resx). Както вече споменахме, ако не използваме динамична компилация, code-behind файловете също няма да са ни необходими.

Обновяване на приложението

Обновяването на уеб приложението се извършва чрез копиране на всички променени страници и потребителски контроли, както и на асемблито, което съдържа компилираните code-behind класове. Ако има промени в конфигурационните файлове на приложението, те също трябва да бъдат обновени. Работният процес на ASP.NET следи за промени в bin директорията и конфигурационните файлове и ако настъпят такива, автоматично рестартира приложението. След рестартиране първият потребител, който поиска дадена страница, ще предизвика JIT компилация на приложението.

Сигурност в ASP.NET

Концепцията за сигурност е залегнала в основата на ASP.NET. Уеб приложенията, които изграждаме, по всяка вероятност ще се ползват от много на брой потребители и сигурно ще са достъпни през Интернет. Това изисква от ASP.NET да предложи добре развит механизъм за осигуряване на сигурност.

Сигурността в ASP.NET се основава на цялостната система за сигурност в .NET и в частност на модела, базиран на роли (Role-Based Security). ASP.NET предлага модели за автентикация (authentication) и оторизация (authorization), които заедно с предоставените услуги от уеб сървъра (IIS) изграждат цялостната инфраструктура за сигурността в ASP.NET. Въпреки че в темата за сигурност, ще разгледаме автентикацията и оторизацията, нека и сега се спрем на тези две дейности.

Автентикация и оторизация

Преди да разгледаме в детайли как се извършва автентикацията в ASP.NET и оторизацията при достъпа до защитени ресурси, нека обясним първо какво означават термините "автентикация" и "оторизация".

Автентикация

Автентикацията е процесът на разпознаване на даден потребител. Потребителят се представя като предоставя данни за себе си (напр. Потребителско име и парола). Тези данни се проверяват за валидност. Ако са валидни, потребителят се счита за автентикиран. В противен случай му се отказва достъп до система или поискания ресурс. В ASP.NET има три възможности за автентикация: windows, forms и passport автентикация. Ще се спрем по-подробно на всяка от тях след малко.

Оторизация

Оторизацията е процес на свързване на потребител с дадени права. За оторизиран се счита потребител, който има право да работи с поискания ресурс или да извърши конкретната операция. Във веригата на сигурността това е следващият процес след автентикацията – след като разберем кой е потребителят, ние трябва да знаем какви са неговите права. В ASP.NET за оторизация се използва моделът Role-Based Security, т.е. всеки потребител може да е в една или повече роли. Процесът на оторизация може да се извършва не само на ниво потребител, но и на ниво роля.

Видове автентикация в ASP.NET

Както вече споменахме, в ASP.NET има три вида автентикация: windows, forms и passport (всъщност са четири, но четвъртият е none – никаква). Ще разгледаме всеки един от тях, като се спрем на неговите предимства и недостатъци. Ще обсъдим в кои ситуации кой модел да използваме.

Windows автентикация

Windows автентикацията разчита на самата операционна система да предостави информация дали даденият потребител е този, за който се представя. За целта, ако дадена страница е достъпна само за автентикирани потребители, пред потребителя се появява диалогов прозорец. В него той трябва да въведе име и парола:

Така въведените данни се проверяват за валидност спрямо потребителите на сървъра или на домейна, в който той се намира. Ако са валидни, потребителят се счита за автентикиран.

Как ще се запази информацията, че даден потребител вече е автентикиран, зависи от настройките, които направим на уеб сървъра. Възможностите са следните: basic, digest и integrated оторизация. Нека да разгледаме всяка от тях накратко:

Basic автентикация

Това е най-простият метод за автентикация и най-непрепоръчителният, защото паролата се предава в чист вид в HTTP хедъра на всяка заявка. Предимствата на този метод са, че е официално приет стандарт и се поддържа от всички съвременни браузъри.

Digest автентикация

Подобна е на basic автентикацията с едно единствено предимство – името и паролата не се предават в чист вид. Въпреки това изисква самите пароли да са в чист вид (или криптирани) на сървъра, което означава, че достъпът до него трябва да е ограничен.

Integrated Windows автентикация

Това е най-сигурният метод за автентикация в Windows среда. При него не се предава никаква конфиденциална информация (няма диалогов прозорец за въвеждане на данни), а потребителят се автентикира като текущо влезлия (logged) потребител в операционната система, от която идва заявката. Естествено сигурността и удобството имат своята цена – тази възможност се поддържа само от Internet Explorer (уеб сървъра и браузъра осъществяват комуникацията по свой собствен начин). Използват се портове, различни от 80, за да се осъществи автентикацията, което може да е проблем, ако има защитна стена (firewall) в мрежата.

След като разгледахме всяка една от възможностите за Windows автентикация, нека да видим как да зададем коя да използваме.

За начало указваме да се използва Windows автентикация в конфигурационния файл на приложението Web.config:

След това отваряме конфигурационната конзола на IIS и с десен бутон върху нашия проект избираме Properties. От появилия се прозорец избираме етикета Directory Security и натискаме бутона Edit, който се намира в първата секция: Anonymous access and authentication control (вж. фигурата). След това имаме възможност да изберем необходимия ни метод – в случая сме избрали Integrated Windows автентикацията.

Windows автентикацията е най-добре да използваме, ако разработваме приложение, което ще се използва в рамките на една компания (в нейния Интранет), където потребителите са част от потребителския домейн и са фиксиран брой. Този вид автентикация е неприложим, ако приложението ще се използва в Интернет.

Forms автентикация

Това е може би най-често използваният метод за автентикация в ASP.NET. В него самото приложение се грижи за автентикирането на потребителите. След малко ще разгледаме подробен пример как да използваме този вид автентикация, а сега нека разгледаме принципа, на който тя се базира.

Forms автентикация – принцип на действие

При поискване на ресурс (страница), който е разрешен само за автентикирани потребители, клиентският браузър се пренасочва към предварително указана страница, на която ще се извърши автентикацията. При успешна автентикация към клиента се изпраща бисквитка, която указва, че потребителят е вече автентикиран. При всяка следваща заявка бисквитката се прихваща и използва от ASP.NET за разпознаване на автентикираните потребители.

Forms автентикацията е най-масово използваният метод за автентикация, защото е много удобен за реализиране на конкретна логика за управление на потребителите. Този метод е и най-удобен, ако разработваме приложения, които ще се ползват в Интернет, където броят на потребителите е силно динамичен. Единственото неудобство е, че разчита на бисквитки, но и затова е помислено, като има възможност за сесия без бисквитки – cookieless session.

Автентикация и оторизация чрез Forms authentication и Role-based security – пример

В следващия пример ще разгледаме как може да използваме Forms автентикацията в реална ситуация. Като начало ще зададем използването на Forms автентикация във файла Web.config:

</authentication>

Атрибутът loginUrl се използва, за да укажем на коя страница ще се автентикира потребителят. При поискване на страница, изискваща автентикация, потребителят ще бъде пренасочен към Login.aspx, където ще може да се автентикира. Другата настройка, която трябва да направим в конфигурационния файл, е да укажем кои ресурси ще изискват автентикация. Ето фрагмент от конфигурационен файл, който дефинира всички уеб форми под директорията Admin да изискват автентикирани потребители:

<system.web>

...

</system.web>

<system.web>

</authorization>

</system.web>

</location>

</configuration>

Същото може да се постигне, като поставим Web.config в директорията Admin със следното съдържание:

<system.web>

</authorization>

</system.web>

</configuration>

Нека се спрем малко по-подробно на секцията authorization и нейните дъщерни елементи. Елементът deny отказва достъпа до този ресурс на съответните потребители или роли, като за потребители се използва атрибутът users, а за роли – roles (ако разрешените са повече от една, те са разделени със запетая). Аналогично има елемент allow, който разрешава достъпа. Като стойности на тези атрибути могат да се използват и знаците * (всички потребители) и ? (потребителите, които не са автентикирани). Когато ASP.NET проверява дали потребител има достъп до даден ресурс, правилата се прилагат отгоре надолу. Ако се стигне до правило, което му разрешава или отказва достъп, то се изпълнява, а стоящите под него се игнорират. Ако няма такова, се счита, че потребителят има достъп до поискания ресурс.

Сега ще разгледаме как ще изглежда нашата форма за влизане в системата. Ето съществената част от Login.aspx файла:

<tr>

<td>Username :</td>

<td>

<asp:TextBox id="TextBoxUsername" runat="server" />

</td>

</tr>

<tr>

<td>Password :</td>

<td>

<asp:TextBox id="TextBoxPassword" runat="server"

TextMode="Password" />

</td>

</tr>

<tr>

<asp:Button id="ButtonLogin"

runat="server" Text="Login" />

</td>

</tr>

<tr>

<asp:Label id="LabelErrorMessage" runat="server" />

</td>

</tr>

</table>

</form>

Ето и как ще изглежда формата в клиентския браузър:

Сега ще разгледаме кода, който извършва автентикацията. Методът, който обработва събитието Click на бутона ButtonLogin, е в code-behind файла на формата Login.aspx:

private void ButtonLogin_Click(object sender, EventArgs e)

{

if (TextBoxUsername.Text == TextBoxPassword.Text)

{

FormsAuthentication.RedirectFromLoginPage(

TextBoxUsername.Text, false );

}

else

{

LabelErrorMessage.Text = "Invalid login!";

}

На първия ред извършваме наивна валидация на потребителското име и парола, като ги сравняваме дали са равни. В реална ситуация ще ни се наложи да се обърнем към базата от данни или да извикаме уеб услуга, за да установим дали данните са валидни. В случай, че са валидни, трябва да извикаме статичния метод RedirectFromLoginPage(…) на класа FormsAuthentication. Той приема два параметъра: потребителското име, което ще се запише в бисквитката за автентикация и флаг, дали тази бисквитка да остане за определено време при клиента (продължителността се конфигурира в Web.config). Вторият параметър служи да се избегне операцията по автентикация, ако затворим браузъра. Методът пренасочва потребителя към първоначално поискания от него ресурс, който е изисквал автентикация. Ако искаме да го пренасочим на друго място, трябва да използваме друг статичен метода SetAuthCookie(…), който само изпраща бисквитката за автентикация. Друг полезен метод на класа FormsAuthentication е HashPasswordForStoringInConfigFile(…). Той служи за хеширане на потребителските пароли. Ако потребителят не е въвел правилно своите данни, изписваме съобщение за грешка.

Не съобщавайте на потребителите дали са сбъркали само името или само паролата. Това може да ги насочи към потребителските имена на съществуващи потребители и да доведе до пробиви в сигурността на приложението.

След като проследихме как става автентикацията, нека да разгледаме как се извършва оторизацията чрез сигурност, базирана на роли. Единственият код, който трябва да напишем за целта, е в Global.asax.cs файла:

protected void Application_AuthenticateRequest(Object sender,

EventArgs e)

{

if (HttpContext.Current.User != null)

{

if (HttpContext.Current.User.Identity.IsAuthenticated)

{

FormsIdentity identity =

HttpContext.Current.User.Identity as FormsIdentity;

if (identity != null)

{

if (identity.Name == "Stefan" )

{

HttpContext.Current.User = new GenericPrincipal(

identity, new string[]{ "Web Developer" } );

}

Методът Application_AuthenticateRequest се извиква, когато даден потребител бъде автентикиран. Ето какво правим в този случай. Проверяваме дали наистина е автентикиран и ако е така, проверяваме дали се използва Forms автентикация. Ако такава е налична, може да използваме свойството Name на обекта identity, което ни връща вече съхраненото име за потребителя в бисквитката за автентикация. След това реализираме логиката за задаване ролите на потребителя, който се е автентикирал. В случая на потребителя "Stefan" се задава роля "Web Developer", което ще му позволи достъп до всички ресурси, които са разрешени както за него, така и за неговата роля.

Passport автентикация

Този метод се базира на услугата MS Passport, която Microsoft предлага на своите клиенти. Тази услуга всъщност представлява голямо единно хранилище на информация за регистрирали се потребители. Информацията за тях е достъпна през уеб услуги. Идеята на тази услуга е, че потребителят влиза в системата само веднъж и след това може да влиза директно и в други сайтове, използващи същата автентикация. Излизането може да стане както от текущия сайт, така и от всички сайтове, в които е влязъл потребителят. Предимствата на този подход са, че се предоставя единен механизъм за работа с потребители (единна база от данни), както и че има високо ниво на сигурност. Недостатъците са, че услугата не е безплатна, а и работата на приложението става зависимо от трета страна (в случая Microsoft).

Сигурност на ниво сървър (IIS Security)

За финал ще разгледаме какво ни предоставя IIS сървъра за осигуряване на сигурност на приложението. Основното предназначение на един уеб сървър е да обслужва заявките, направени от клиентските браузъри към ресурси, които се намират на сървъра. Поисканият ресурс може да не съществува или клиентът да няма право да го види.

Разглеждане файловете на сървъра

Стандартно IIS разрешава достъпа само до определени ресурси (*.aspx, *.html, *.jpg и др.), останалите файлове не се обслужват (напр. Web.config, *.cs и др.).

Ако е необходимо отдалечено разглеждане на файловете на приложението, може да го разрешим, като маркираме настройката Directory Browsing, намираща се в менюто Properties, щраквайки с десен бутон върху уеб приложението в потребителския интерфейс на IIS.

На фигурата по-долу е показан диалогът за настройка на "Directory Browsing" опцията.

Анонимен достъп

Поискването на ресурс от файловата система на уеб сървъра трябва да се идентифицира с валиден потребител на системата. Всяка заявка, направена от клиентски браузър към ресурс, за който е разрешен анонимен достъп, се идентифицира като анонимна (стига да не е направена чрез Internet Explorer, чийто потребител е в мрежата на сървъра) и се асоциира със служебния потребител IUSR_machinename, където machinename е името на сървъра. Този потребител се добавя в системата при инсталацията на сървъра.

Ако искаме да разрешим анонимен достъп до файловете и/или да променим потребителя, с който се асоциира анонимния достъп, отново трябва да щракнем с десен бутон върху приложението и да изберем Properties.

Този път трябва да изберем Directory Security и щракаме върху бутона Edit, който се намира в първата секция: Anonymous access and authentication control.

Не давайте по-големи права от необходимите за достъп на акаунта IUSR_machinename.

Криптиране на връзката чрез SSL

Уеб сървърът (IIS) предлага и възможност за криптиране на връзката, като за целта се използва най-разпространеният стандарт Secure Sockets Layer (SSL). Стандартно браузърът и сървърът комуникират като си пращат информацията в прав текст. Използвайки SSL сертификат, двете страни по сигурен начин обменят ключ, който ще се използва за криптиране на комуникацията между тях. Дори и недоброжелател да прихване предаваната информация, той няма да е в състояние да ги декриптира (поне в разумни срокове и с нормални технически средства). За да се използва SSL, на сървъра трябва да се инсталират необходимите сертификати. Те могат да бъдат издадени единствено от определените органи за това (Certification Authorities). Стандартно SSL комуникацията протича на порт 443 и може да се познае по това, че адресът на сайта започва с https://.

Упражнения

1. Създайте уеб проект. Разгледайте генерираните файлове и обяснете за какво служи всеки един от тях. Покажете code behind файловете. Отпечатайте "Hello world" в aspx файл и в code behind файл. Покажете файловете, автоматично генерирани в папката Assembly. GetExecutingPath().

2. Създайте HTML форма, която предава съдържанието на textarea поле към сървъра и сървърът го отпечатва в ново поле. Не използвайте code-behind файл.

3. Създайте ASP.NET уеб форма, която предава съдържанието на textarea поле към сървъра, който го отпечатва в ново поле.

4. Използвайте src атрибута на @Page директивата, за да направите страница, която няма нужда от компилация.

5. Създайте уеб форма, която по параметри зададени в GET заявката да определя широчината на текстова кутия, адреса на хипервръзка и височината на картинка. Формата да се направи в два варианта – с помощта на HTML и на Web сървърни контроли.

6. Създайте уеб форма, която да има две текстови полета и един бутон. При натискане на бутона да се извърши проверка на клиентската страна дали двете текстови полета имат еднаква стойност и само тогава формата да се подаде на сървъра.

7. Създайте уеб форма с текстово поле и бутон. При натискането на бутона отпечатайте въведения текст в контрола от тип Label и в друг Web server контрола от тип TextBox в режим MultiLine. Въведете в текстовото поле некоректни символи и отстранете HTML escaping проблема, където той се появява. Обяснете работата на контролите.

8. Прихванете събитията за всички етапи от живота на страниците с помощта на методи и реализирайте проследяване за тях.

9. Създайте потребителска контрола, който да визуализира меню. Контролата трябва да има свойства за инициализация на менюто – двумерен масив съдържащ името и страницата на съответния елемент. Имплементирайте свойство, което да определя цвета и шрифта на менюто. Преценете има ли нужда от ViewState поддръжка.

10. Създайте HTML страница, която да отпечатва типа на браузъра, IP-то и порта, който клиента използва, за да отвори страницата.

11. Създайте уеб страница, която да запазва съдържанието на текстово поле в Session обекта и да го отпечатва в поле от тип етикет.

12. Създайте две страници, които да си предават информация въведена от потребителя чрез бисквитка. Бисквитката трябва да е валидна 5 мин.

13. Създайте страница, която да показва таблица, в която на всеки ред има разположени Label контроли и един бутон. При натискане на бутона, Label контролите на текущия ред да се скрият и да се покажат TextBox контроли с текущото съдържание на Label контролите. При повторно натискане на бутона, да се върне първоначалното състояние. Да не се използват по-усложнение контроли като DataGrid, DataList и подобни.

14. Създайте форма за регистрация на потребители с данни за име, имейл, парола, повтаряне на паролата, телефон и опция за съгласие с общите условия на сайта. Всички полета са задължителни и съобщенията за грешки да се извеждат в обща контрола. Полетата за имейл и телефон да се валидират с регулярен израз, а двете полета за парола да се проверяват дали са с еднаква стойност.

15. Създайте уеб форма, която съдържа DataGrid контрола. Реализирайте свързване с таблици от базата от данни Northwind и реализирайте избор, редактиране и триене на редове. сортиране и страниране на резултатите.

16. Визуализирайте данните от таблица с помощта на Repeater контрола.

17. Създайте уеб сайт с "login" страница, страница за административен достъп и страница за публичен достъп. Реализирайте и "logout" функционалност. Използвайте Forms authentication и роли на потребителите.

18. Създайте уеб страница, която да има три бутона и едно поле – етикет. С единият бутон да се инициализира Cache обекта със стойност, която "остарява" след 10 секунди. С вторият бутон – стойност, която да "остарява" 10 секунди след настоящия момент. С третият бутон да се извежда стойността на този елемент от кеша и да се показва в етикета.

19. Създайте потребителска контрола, който да използва изходящо кеширане със зависимост по елемент от Cache обекта.

20. Покажете идентичността на процеса, който изпълнява ASP.NET проекта, при модел на работа на IIS 5.1 и IIS 6.0 с помощта на следните методи:

- Page.User.Identity.Name;

- System.Security.Principal.WindowsIdentity.GetCurrent().Name;

- System.Threading.Thread.CurrentPrincipal.Identity.Name;

21. Създайте уеб страница, която да създаде празен файл в Program Files папката. Конфигурирайте правилно правата на папката, така че да бъде разрешено писането на IIS процеса.

Използвана литература

1. Михаил Стойнов, ASP.NET уеб базирани приложения – http://www. nakov.com/dotnet/lectures/Lecture-15-ASP.NET-and-Web-Applications-v1.01.zip

2. MSDN Documentation - http://msdn.microsoft.com/

3. World Wide Web Consortium (W3C) - The HTML Coded Character Set – http://www.w3.org/MarkUp/html-spec/html-spec_13.html както и по-пълен списък http://www.natural-innovations.com/wa/doc-charset.html

4. Jeff Prosise, Programming Microsoft .NET, Microsoft Press, 2002, ISBN 0735613761

5. Andrew Duthie , Microsoft ASP.NET Programming with Microsoft Visual C# .NET Version 2003 Step by Step, Microsoft Press, 2003, ISBN 0735619352

Глава 17. Многонишково програмиране и синхронизация

Автори

Александър Русев

Иван Митев

Необходими знания

- Базови познания за .NET Framework и CLR

- Базови познания за общата система от типове в .NET (Common Type System)

- Базови познания за езика C#

- Базови познания по операционни системи

- Атрибути

Съдържание

- Многозадачност

- Проблемът – защо многозадачност?

- Ползите от многозадачността

- Решението – процеси и нишки

- Какво предлагат нишките и кога са удобни?

- Видове многозадачност

- Имплементации на многозадачност

- Домейни на приложението

- Нишки

- Как работят нишките?

- По-важни членове на класа Thread

- Приоритет на нишките

- Състояния и живот на нишките

- Thread Local Storage

- Thread-Relative Static Fields

- Повреждане на данни и други неудобства

- Синхронизация

- Най-доброто решение

- Стратегии за синхронизация

- Синхронизирани пасажи код

- Синхронизирани контексти

- MethodImplAttribute

- Неуправлявана синхронизация – WaitHandle

- Класически синхронизационни проблеми

- Пул от нишки - ThreadPool

- Интерфейсът ISynchronizeInvoke

- Таймери

- Асинхронни извиквания

- Асинхронни извиквания на методи и приложения

- Асинхронно извикване чрез делегат

- Модел за асинхронни извиквания

- Интерфейсът IAsyncResult

- Приключване на асинхронен метод

В тази тема ...

В настоящата тема ще разгледаме многозадачността в съвременните операционни системи и средствата за паралелно изпълнение на програмен код, които ни предоставя .NET Framework. Ще обърнем внимание на нишките (threads), техните състояния и управлението на техния жизнен цикъл – стартиране, приспиване, събуждане, прекратяване и др.

Ще разгледаме средствата за синхронизация на нишки при достъп до общи данни, както и начините за изчакване на зает ресурс и известяване при освобождаване на ресурс. Ще се спрем на синхронизационните обекти в .NET Framework, както и на неуправляваните синхронизационни обекти на операционната система.

Ще изясним концепцията за работа с вградения в .NET Framework пул от нишки (thread pool), начините за асинхронно изпълнение на задачи, средствата за контрол над тяхното поведение и препоръчваните практики за работа с тях.

Многозадачност

В тази първа точка от темата ще обясним какво е многозадачността и какъв смисъл има от нея. Казано накратко, многозадачността е възможността на процесора да разпределя времето си върху повече от една задача.

Проблемът

Често на едно приложение се налага да извършва времеотнемащи операции. Докато те се изпълняват, потребителят трябва да бъде известяван за статуса на работа. Той трябва да е наясно дали приложението продължава да извършва обработки или е блокирало.

В други случаи едно приложение трябва да изчаква освобождаването на споделен ресурс, за да може да продължи работата си. Този и горният сценарии демонстрират необходимостта от механизъм, който да позволява поддръжка на паралелно изпълнение на няколко операции.

Ползите от многозадачността

В случаите на многопроцесорни системи многозадачността води до повишена производителност. Когато изпълнението на приложението е разделено на части, които могат да бъдат изпълнени независимо една от друга, то те могат да се разпределят между процесорите и да приключат за по-малко време.

В еднопроцесорните системи, многозадачността е не по-малко важна, защото позволява на приложението да взаимодейства по-добре с потребителя, като постоянно го известява за състоянието си и е способно да отговаря на действията му във всеки момент.

Многозадачността е много полезна и когато една система се използва от много потребители едновременно. Разпределянето на процесорното време между потребителите, чрез помощта на нишките, създава за всеки един от тях илюзията, че работи сам с приложението. Същевременно не се изразходват излишни системни ресурси за поддържане на цял процес за всеки потребител.

Защо е нужна многозадачност – пример

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

При стартиране на програмата, виждаме следното:

Графичният интерфейс на приложението се състои само от едно текстово поле, в което потребителят да въвежда произволен текст и бутон, в обработката на който стои следната времеотнемаща операция:

private void buttonStartJob_Click(object sender, System.EventArgs e)

{

// Start the job in the current thread

new TimeTakingJob().Job();

}

Класът TimeTakingJob има следната реализация:

class TimeTakingJob

{

public void Job()

{

long sum = 0;

for (int i=0; i<100000; i++)

{

for (int j=0; j<100000; j++)

{

if (i==j)

{

sum++;

}

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

Как работи примерът?

Когато потребителят натисне бутона, това тежко изчисление започва да се изпълнява в главната нишка на приложението. Ще дефинираме какво точно е нишка в следващата точка, засега можем да считаме нишката за част (единица) от приложението.

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

Алтернативата

За да се избегне този проблем, кодът, който се изпълнява при натискането на бутона, трябва да изглежда подобно на следния:

private void buttonStartJob_Click(object sender, System.EventArgs e)

{

// Start the job in a seperate thread

Thread t = new Thread(

new ThreadStart(new TimeTakingJob().Job));

t.Start();

}

Тогава изчислението се пуска в отделна нишка и потребителският интерфейс реагира коректно. Работа на процесора е да разпредели времето си между нишката за изчислението и нишката за интерфейса.

Решението – процеси и нишки

Процесът е съвкупността от памет, стек и код на приложението. Операционната система работи с процеси, които потребителите възприемат като приложения - това са две имена за едно и също понятие. Както видяхме в предишния пример, един процес може да изисква паралелно изпълнение на повече от една задача. Затова процесите са съставени от една или повече нишки, които се изпълняват едновременно от гледна точка на потребителя (всъщност тази илюзия се постига, като процесорът често и бързо превключва между тях). Нишката е основната единица, за която се заделя процесорно време.

Процеси и нишки

Ще се спрем на приликите и разликите между процесите и нишките.

Както процесите, така и нишките, имат собствен стек и имат определен приоритет. Процесите са независими един от друг по отношение на памет и данни. За разлика от тях, всички нишки в един процес споделят обща памет – паметта на процеса, към който принадлежат.

Докато процесите съдържат изпълнимия код, нишките го изпълняват – процесите са пасивни, а нишките – активни.

Какво предлагат нишките?

Използването на няколко нишки създава впечатление за извършване на много задачи едновременно. Причината е, че процесорът се предоставя на всяка нишка за някакъв определен интервал от време (квант). Разпределянето на времето се осъществява на базата на различни стратегии.

След изтичането на този квант, се получава прекъсване и процесорът се предоставя на следващата чакаща нишка. Прекъсването е механизъм, позволяващ нормалната последователност от процесорни инструкции да бъде променена. Този тип прекъсвания са известни като софтуерни прекъсвания – те са предварително планирани и синхронни с работата на процесора. Освен тях, процесорът може да получава и хардуерни прекъсвания, които са асинхронни, т. е. могат да постъпят в произволен момент. Те също водят до промяна в изпълняваната последователност от инструкции.

Именно механизмът на прекъсванията през достатъчно малък интервал от време създава впечатлението за едновременно изпълнение на повече операции. Когато например потребителят въвежда данни в текстообработваща програма, други данни могат да се печатат на принтер. Би било неудобно за потребителя ако не може да върши друга работа, докато принтерът работи.

Кога са удобни нишките?

Удобно е да се ползват нишки при обслужване на много потребители едновременно, напр. при приложение от тип уеб сървър. Когато потребител се свърже, се пуска нова нишка, чрез която да работи. Аналогично е и свързването с база от данни, всяка връзка към нея се обслужва от отделна нишка.

При мрежова комуникация (напр. през сокети), комуникацията може да бъде изолирана в отделна нишка и докато приложението чака отговор от другата страна, да извършва друга полезна работа.

Всяка нишка има приоритет. Нишките с по-висок приоритет заемат процесора по-често. Така можем да определяме приоритети на отделните задачи в едно приложение.

Изпълняването на дълги изчисления (като в примера), винаги трябва да става на заден план, за да може потребителският интерфейс да реагира на потребителски заявки.

Многозадачност – видове

Съществуват два вида многозадачност – кооперативна и изпреварваща.

При кооперативната многозадачност (cooperative multitasking), всяка нишка сама решава колко процесорно време й е необходимо. Веднъж заела процесора, тя го освобождава само ако приключи работата си или трябва да чака за някакъв ресурс – напр. дадено събитие или вход от потребителя. Това обаче може да доведе до безкрайно отлагане (starvation) на останалите нишки и те да чакат неопределено дълго. В чистия й вид, кооперативната многозадачност има много ограничени приложения.

При изпреварващата многозадачност (preemptive multitasking), за всяка нишка предварително се заделя процесорно време. Системен софтуер, наречен планировчик (task scheduler), е отговорен за това разпределение на времето. В края на всеки такъв предварително зададен интервал от време, нишката се снема от процесора, без значение дали е приключила работата си.

В съвременните операционни системи (Windows 2000, Windows XP), се използва изпреварваща многозадачност. Тя е по-безопасна, тъй като при нея процесорът не може да бъде зает от една нишка за неопределено време и няма риск от безкрайно отлагане за останалите.

Някои системи използват комбиниран вариант – нишките с висок приоритет заемат процесора до приключването си (кооперативно), а останалите – на интервали (изпреварващо).

Имплементации на многозадачност

Многозадачността може да бъде имплементирана по два начина – самостоятелна многозадачност (Apartment Threading) и свободна многозадачност (Free Threading).

При самостоятелната многозадачност, всеки процес получава копие на данните, нужни за неговото изпълнение. Всяка нишка се стартира в неин собствен процес, така че няма споделени данни между нишките в един процес. Всяка работа, която искаме да извършим в нишка, се извършва в отделен процес. Тази многозадачност е извънпроцесна (out-of-process).

При свободната многозадачност данните в процеса са споделени между нишките и процесорът може да смени нишката, като в същото време не сменя данните, с които се работи.

Свободната многозадачност (Free Threading) е по-ефективното решение и затова се използва по-често в практиката. В .NET Framework нишките използват именно Free Threading модела.

Самостоятелна многозадачност

При модела на самостоятелната многозадачност (STA) всяка нишка "живее" в отделен апартамент в рамките на процеса. Процесът може да има произволен брой апартаменти и те да споделят данни помежду си чрез посредник (proxy). Приложението решава кога и за колко дълго трябва да се изпълнява нишката във всеки апартамент. Всички заявки се сериализират чрез Windows опашка със съобщения, така че по всяко време се достъпва само един апартамент и следователно само една нишка се изпълнява. STA е моделът, който познават повечето Visual Basic разработчици, защото преди появата на VB.NET само той е бил достъпен за VB приложенията.

Свободна многозадачност

При свободната многозадачност (MTA) данните в процеса са споделени между нишките и процесорът може да смени нишката, като в същото време не сменя данните, с които се работи. Този подход се използва често, защото позволява повишена ефективност. В .NET Framework се поддържа именно Free Threading модела, но за взаимодействие с COM има предвидени начина за работа със STA.

Домейни на приложението (Application Domains)

Когато се стартира едно .NET приложение, операционната система създава неуправляван процес. Приложението обаче не може да се изпълнява директно в неуправлявания процес. Затова се въвежда допълнително ниво на абстракция между приложението и процеса, наречено домейн на приложението. Домейнът е логическо понятие, за разлика от процеса, който е физически. Един неуправляван процес съдържа един или повече управлявани домейни на приложението.

Домейни на приложението – предимства

- По принцип процес не може да ползва данни на друг процес. Това ограничение може да бъде заобиколено с употребата на посредник (proxy), но това обикновено става за сметка на усложняване на кода. Използвайки домейни на приложението, можем да стартираме повече от едно приложение в един и същ процес. Така споделянето на данни между приложенията бива значително улеснено

- Домейните на приложението допълнително се разделят на контексти. Контекстът е също логическо понятие. Обектите, опериращи в един контекст, са контекстно свързани обекти. За контекстно свързаните обекти, .NET Framework предоставя допълнителен механизъм за синхронизация, който ще бъде разгледан в точката за синхронизация.

- Домейните на приложението поддържат проверка на типа на данните, които съдържат.

Също като процесите, домейните на приложението могат да съдържат една или повече нишки.

За достъп до домейн на приложението .NET Framework предоставя класа System.AppDomain.

Нишки

Нишките (threads) предоставят възможност на процесора да изпълнява няколко задачи едновременно, като паралелното изпълнение се симулира чрез постоянно превключване между задачите през много кратки интервали от време. Всяка нишка изпълнява някаква задача (програмен код) като от време на време заема процесора за много кратко време, след което го освобождава за изпълнение на друга нишка.

Как работят нишките?

Нека разгледаме принципната схема на работа на планировчика на задачите (task scheduler), който разпределя процесорното време между всички активни нишки.

От схемата се вижда, че в даден момент се поддържат известен брой текущо изпълнявани нишки (в дясната колона). Тъй като процесорът е един, те са подредени в опашка и всяка изчаква своя ред. Когато една нишка получи достъп до процесора, на нея се предоставя квант от време (time slice). Той започва с поредната за изпълнение процесорна инструкция и завършва с инструкция за прекъсване, което е знак за процесора да запомни регистрите на нишката, която е изпълнявал (т. е. да запази докъде е стигнало изпълнението на нишката). Междувременно, нишката се връща в опашката, откъдето се избира следващата за изпълнение. Тя започва от там, до където е стигнала при последното си заемане на процесора и процесът се повтаря циклично.

Изпълнение на няколко нишки – пример

Ще дадем следния пример за демонстрация:

SmallExample.cs

using System;

using System.Threading;

namespace SmallExample

{

class ThreadClass

{

public void DoTask1()

{

for( int i=0; i<100; i++ )

{

Console.WriteLine("Thread1:job({0})",i);

Thread.Sleep(1);

}

public void DoTask2()

{

for( int i=0; i<100; i++ )

{

Console.WriteLine("Thread2:job({0})",i);

Thread.Sleep(1);

}

class MainThread

{

static void Main(string[] args)

{

ThreadClass threadClass = new ThreadClass();

Thread thread1 = new Thread(

new ThreadStart(threadClass.DoTask1));

Thread thread2 = new Thread(

new ThreadStart(threadClass.DoTask2));

thread1.Start();

thread2.Start();

}

Как работи примерът?

Главната нишка на приложението започва изпълнение от метода Main(…) на класа MainThread. Със създаването на два обекта от клас Thread, създаваме две нишки. При създаването на нишка, подаваме като параметър метода, от който тя да започне изпълнението си. В случая, това са методите DoTask1() и DoTask2() на класа ThreadClass. ThreadStart e делегат, който определя сигнатурата на метода - тяло на нишката, а именно – метод без параметри, който не връща стойност.

С извикването на метода Start() на двете нишки, всяка от тях започва да се изпълнява и върху конзолата започва да се изписва коя до къде е стигнала. При стартиране на примера се вижда, че често двете нишки приключват почти едновременно, тъй като изпълняват еквивалентен код.

Класът Thread

В .NET Framework за изпълнение на нишки се използва класът System. Threading.Thread. Този клас предоставя функционалност за стартиране и управление на нишки. Нека разгледаме неговите по-важни членове:

Thread (ThreadStart)

Създава инстанция. Подава се делегат с метод, който да се изпълни при стартиране. Създаването на нишка вече бе демонстрирано.

Sleep(...)

"Приспива" текущата нишка за указания брой милисекунди. Методът е статичен и блокира текущо изпълняваната нишка. След изтичането на зададения интервал, тя продължава работата си.

Suspend()

Ако нишката работи, я преустановява временно. Ако е преустановена, не се случва нищо. За разлика от Sleep(), чрез който нишка преустановява себе си за някакъв фиксиран интервал от време, Suspend() преустановява нишка за неопределено време и тя остава в това състояние до извикването на Resume(), който подновява изпълнението й.

Resume()

Подновява нишка, която е била преустановена (suspended). Ако нишката работи, не прави нищо.

Некоректното използване на Suspend() и Resume() може да доведе до синхронизационни проблеми. Ако две нишки взаимно се чакат за Resume(), нито една няма да може да продължи и ще се стигне до "мъртва хватка" (deadlock).

Suspend() и Resume() – пример

Като пример за Suspend() и Resume(), ще дадем едно кратко Windows Forms приложение. При стартиране то печата даден текст буква по буква със забавяне между отделните букви. Визуално приложението изглежда по следния начин:

Нека разгледаме съществената част от сорс кода на примерното приложение:

delegate void CharParamDelegate(char aChar);

private const string MESSAGE="This application demonstrates " + "Thread.Suspend() and Thread.Resume() methods. ";

private Thread mThread;

private System.Windows.Forms.TextBox textBoxMessage;

private System.Windows.Forms.Button buttonResume;

private System.Windows.Forms.Button buttonSuspend;

private void MainForm_Load(object sender, System.EventArgs e)

{

mThread = new Thread(new ThreadStart(this.PrintMessages));

mThread.IsBackground = true;

mThread.Start();

SuspendThread();

}

private void SuspendThread()

{

mThread.Suspend();

buttonSuspend.Enabled = false;

buttonResume.Enabled = true;

}

private void ResumeThread()

{

mThread.Resume();

buttonSuspend.Enabled = true;

buttonResume.Enabled = false;

}

private void AppendTextToTextBox(char aChar)

{

textBoxMessage.AppendText(aChar.ToString());

}

/// <summary>

/// PrintMessages() runs in a separate thread and slowly

/// prints messages in the MainForm's text box.

/// </summary>

private void PrintMessages()

{

while (true)

{

foreach (char letter in MESSAGE.ToCharArray())

{

try

{

this.Invoke(new CharParamDelegate(

AppendTextToTextBox), new object[]{letter});

}

catch (Exception)

{

// Can not call Invoke() bacause the form is closed.

return;

}

Thread.Sleep(50);

}

private void buttonSuspend_Click(object sender,

System.EventArgs e)

{

SuspendThread();

}

private void buttonResume_Click(object sender,

System.EventArgs e)

{

ResumeThread();

}

Как работи примерът?

При зареждане на формата, се пуска една нишка, която във вечен цикъл изписва даден текст в текстово поле символ по символ. Преди да я пуснем, установяваме в true свойството й IsBackground, с което я пускаме във фонов режим. Така тя ще спре автоматично при приключване на главната нишка, т. е. при затварянето на формата. Двата бутона викат съответно методите Suspend() и Resume() и определят в дадения момент кой бутон да бъде позволен.

Отпечатването на всеки отделен символ минава през метода Form. Invoke(…). По този начин потребителският интерфейс на приложението се променя единствено от главната нишка на приложението.

Не променяйте графичния потребителски интерфейс от външна нишка. Последствията могат да бъдат непредсказуеми: забавяне, "зависване", повреда на данни и др.

IsAlive

Свойството IsAlive има стойност true, след като нишката се стартира. Нормалното приключване на нишката или прекратяването й поради външна намеса променят стойността на IsAlive на false. Повече информация за състоянията, през които една нишка преминава, дава ThreadState.

IsBackground

Свойство за четене и запис. Една нишка може да е на преден (foreground) или заден (background) план.

Когато всички нишки на преден план в един процес приключат, той приключва. CLR вика Abort() за всички нишки на заден план (известни още като нишки, работещи във фонов режим).

IsThreadPoolThread

Свойство за четене и запис. Има стойност true, ако нишката принадлежи на управлявания пул от нишки, иначе е false.

Name

Свойство за четене и запис на името. Всяка нишка в .NET Framework може да има име. Това свойство е полезно за идентифицирането на нишките при дебъгване и извеждане на диагностични съобщения.

Priority

Свойство за четене и запис на приоритета на нишката. Възможните стойности са Lowest, BelowNormal, Normal (по подразбиране), AboveNormal и Highest.

ThreadState

Свойство само за четене. Съдържа състоянието на нишката. Състоянията, в които една нишка може да попадне, ще бъдат подробно обяснени в следващата точка – засега можем да считаме, че състоянието на една нишка определя например дали текущо тя работи или изчаква.

Abort()

Хвърля ThreadAbortException в извиканата нишка, с което обикновено прекратява нишката. При определени условия, Abort() може и да не прекрати нишката. Това ще бъде обяснено в точка "Прекратяване".

Interrupt()

Ако нишката е в състояние WaitSleepJoin, хвърля ThreadInterruptedException. Нишката може да прихване това изключение и да продължи изпълнението си. Ако тя не го прихване, CLR го прихваща и прекратява нишката.

Ако нишката не е в състояние WaitSleepJoin, извикването на Interrupt() не прави нищо.

Join()

Извикващата нишка изчаква, докато извиканата приключи. Може да се укаже таймаут.

Join() – пример

Това е познатият ни пример SmallExaple.cs, но тук главната нишка спира работата си и продължава едва след приключването на другите две.

static void Main(string[] args)

{

Console.WriteLine("Main thread started.");

ThreadClass threadClass = new ThreadClass();

Thread thread1 = new Thread(

new ThreadStart(threadClass.DoTask1));

Thread thread2 = new Thread(

new ThreadStart(threadClass.DoTask2));

thread1.Start();

thread2.Start();

thread1.Join();

thread2.Join();

Console.WriteLine("Main thread finished.");

}

Стартирането на програмата води до следния резултат:

Start()

Стартира посочената нишка. Операцията не е блокираща (връща управлението веднага). При извикване на Start() операционната система създава нова нишка и сменя състоянието й в Running. При опит за повторно стартиране, се хвърля ThreadStateException.

Приоритет

В повечето имплементации на многонишковост (multithreading), се поддържа и приоритет за нишките. На базата на приоритета, планировчикът (task scheduler) определя интервала от време, който следва да бъде отделен на нишката. Операционната система не е длъжна да се съобразява с предварително зададения приоритет, но обикновено го прави.

Приоритет – пример

Ще направим нова промяна в SmallExample.cs. Преди да стартираме двете нишки от главната, ще променим приоритета на едната.

…

thread2.Priority = ThreadPriority.Highest;

thread1.Start();

thread2.Start();

…

Ще оставим на читателя сам да направи сравнението на резултатите.

Състояния

Както видяхме в примерите до момента, всяка нишка минава през различни състояния по време на своето съществуване – например да изчаква или да се изпълнява. Текущото състояние на нишката се съдържа в променливата ThreadState. Една нишка може да се намира и в повече от едно състояние на изброения тип ThreadState (понеже той има атрибут FlagsAttribute, който позволява побитово комбиниране на стойностите му). Отделните състояния са следните:

- Unstarted – нишката е създадена, но не е извикан метода Start(). В момента, в който Start() бъде извикан, нишката преминава в състояние Running и по никакъв начин не може да се върне обратно в това състояние.

- Running – нишката е стартирана, не е блокирана и не очаква да получи ThreadAbortedException (изключение, което се хвърля при извикване на метода Abort()).

- WaitSleepJoin – нишката е блокирана, след като е бил извикан някой от методите Wait(), Sleep() или Join().

- SuspendRequested – за нишката е извикан метода Suspend(), но все още не е преустановена, а се изчаква безопасен момент това да се извърши.

- Suspended – нишката вече е преустановена.

- AbortRequested – извикан е методът Abort() за нишката, но тя още не е получила изключението ThreadAbortException, което ще се опита да я прекрати.

- Aborted – нишката вече е прекратена като едновременно с това се намира и в състоянието Stopped.

- StopRequested – от нишката е поискано да прекрати работата си.

- Stopped – нишката е прекратена или след като й е бил извикан методът Abort(), или след като е приключила по естествен начин.

- Background – нишката е във фонов режим.

Живот на нишките

Съвкупността от всички състояния, през които една нишка може да премине по време на своето съществуване, определя нейния жизнен цикъл. Запознахме се със състоянията и методите, които предизвикват преходите между тях. Сега ще илюстрираме казаното със следната схема на състоянията и преходите:

Прекратяване на нишка

Една нишка може да бъде прекратена безусловно чрез извикване на метода Thread.Abort(). Извикването на този метод предизвиква ThreadAbortedException в нишката, за която е извикан. Това изключение е по-специално, тъй като след евентуалната си обработка в catch блока на нишката, то се хвърля повторно от CLR. С повторното хвърляне на изключението, CLR изпълнява всички finally блокове и приключва нишката. Прекратяването на нишката може да се забави неопределено дълго, в зависимост от изчисленията във finally, затова се препоръчва извикване на метода Join(), за да сме сигурни, че нишката е приключила. Повторното хвърляне на ThreadAbortedException може да бъде отменено чрез извикване на Thread.ResetAbort() в catch блока на прекратяваната нишка - тогава тя ще продължи изпълнението си.

Ако нишката навлезе в неуправляван код и тогава получи заявка за прекратяване, CLR "маркира" нишката и я изчаква да се върне в управляван код.

Използването на Thread.Abort() не е най-добрият начин да контролираме живота на една нишка. ThreadAbortedException е изключение, което трудно да обработено коректно. Съществуват много по-удобни механизми за синхронизация между нишки, с които ще се запознаем по-долу.

Прекратяване на нишка – пример

Ще разширим примера, който дадохме за методите Suspend() и Resume(). Програмата отново изписва текст символ по символ, но имаме възможност и да прекратим нишката във всеки момент. Паралелно с това, се следят състоянията, през които минава нишката.

Единственото, което правим в главната нишка на приложението, е да пуснем две други нишки – mBackgroundThread, която ще е отговорна за изписването на текста, и mStatusWatchThread, която ще следи състоянието на mBackgroundThread. И двете нишки се пускат във фонов режим.

private void MainForm_Load(object sender, System.EventArgs e)

{

BackgroundThread backgroundThread =

new BackgroundThread(this);

mBackgroundThread = new Thread(new

ThreadStart(backgroundThread.DoDisplayMessage));

mBackgroundThread.IsBackground = true;

mBackgroundThread.Start();

StatusWatchThread statusWatchThread =

new StatusWatchThread(this);

mStatusWatchThread = new Thread(new

ThreadStart(statusWatchThread.DoStatusWatch));

mStatusWatchThread.IsBackground = true;

mStatusWatchThread.Priority = ThreadPriority.Highest;

mStatusWatchThread.Start();

}

В класа на формата са предвидени и два метода, чрез които стартираните нишки да променят графичния й интерфейс. Единият добавя нов ред в ListBox контрола, а другият присвоява текст на текстовото поле.

public void DisplayThreadState()

{

string newStateMsg = String.Format("Thread state = [{0}]",

mBackgroundThread.ThreadState);

if (listBoxThreadState.Items.Count != 0)

{

string oldStateMsg = (string) listBoxThreadState.Items[

listBoxThreadState.Items.Count-1];

if (newStateMsg != oldStateMsg)

{

listBoxThreadState.Items.Add(newStateMsg);

}

else

{

listBoxThreadState.Items.Add(newStateMsg);

}

listBoxThreadState.SelectedIndex =

listBoxThreadState.Items.Count-1;

}

public void ShowMessageInTextBox(string aMessage)

{

textBoxMessage.Text = aMessage;

}

Четирите бутона в дясно от текстовото поле викат съответните методи на mBackgroundThread. Няма да даваме тяхната имплементация.

Нишката mBackgroundThread изписва текста буква по буква и обработва възможните изключения. Отново ще подчертаем използването на Form.Invoke(…) тогава, когато потребителския интерфейс на главната нишка се променя от външна нишка.

delegate void StringDelegate(string aString);

public class BackgroundThread

{

private const string MESSAGE =

"This example illustrtates how to use ThreadState, Suspend()"+

", Resume(), Sleep(), Interrupt(), Abort(), Priority and "+

"IsBackground methods and properties of the System.Threading"+

".Thread class.";

private MainForm mMainForm;

public BackgroundThread(MainForm aMainForm)

{

mMainForm = aMainForm;

}

public void DoDisplayMessage()

{

try

{

for (int len=1; len<=MESSAGE.Length; len++)

{

try

{

string msg = MESSAGE.Substring(0, len);

mMainForm.Invoke( new

StringDelegate(mMainForm.ShowMessageInTextBox),

new object[]{msg});

}

catch (Exception)

{

return;

}

Thread.Sleep(100);

}

catch (ThreadInterruptedException)

{

MessageBox.Show("ThreadInterruptedException", "Info");

return;

}

catch (ThreadAbortException)

{

MessageBox.Show("ThreadAbortException", "Info");

}

finally

{

MessageBox.Show("Finally block reached.", "Info");

}

MessageBox.Show("Thread finished by itself.", "Info");

}

Нишката mStatusWatchThread 10 пъти в секундата проверява състоянието на нишката mBackgroundThread и ако настъпи промяна, го отпечатва в ListBox контрола.

delegate void VoidDelegate();

public class StatusWatchThread

{

private MainForm mMainForm;

public StatusWatchThread(MainForm aMainForm)

{

mMainForm = aMainForm;

}

public void DoStatusWatch()

{

while (true)

{

try

{

mMainForm.Invoke(

new VoidDelegate(mMainForm.DisplayThreadState));

}

catch (Exception)

{

return;

}

Thread.Sleep(100);

}

Как работи примерът?

Натискането на бутоните Suspend и Resume води до същия резултат, както и във вече дадения пример. Когато натиснем Abort, това предизвиква ThreadAbortException в mBackgroundThread. Изпълнява се съответния catch блок, след което CLR прекратява нишката, изпълнявайки преди това finally блока. Съобщението, което ни казва, че нишката е приключила сама, не се показва.

Нека в catch клаузата добавим следния ред:

catch (ThreadAbortException)

{

MessageBox.Show("ThreadAbortException", "Info");

Thread.ResetAbort();

}

Сега CLR не унищожава нишката, затова след обработката на изключението и finally блока, нишката продължава и се показва съобщението "Thread finished by itself" ("Нишката завърши сама.").

Thread Local Storage (локални за нишката данни)

Thread Local Storage е контейнер, в който всяка нишка може да съхранява собствени данни. Всеки елемент се съдържа в съответен слот за данни, който се представя от обект от класа System.LocalDataStoreSlot. Нишката може да си създаде такъв слот с методите Thread. AllocateNamedDataSlot(…) или Thread.AllocatеDataSlot(). Ако създаденият слот е наименован, към него можем да се обръщаме и по име, в противен случай е достъпен само по референцията, върната при неговото създаване.

Слот, създаден от дадена нишка, е недостъпен за останалите нишки. Допълнително, ако в рамките на един процес е създаден слот с някакво име и друга нишка се опита да създаде нов слот със същото име, ще се хвърли изключение.

Thread Local Storage – пример

За да илюстрираме работата с Thread Local Storage ще дадем следния пример:

class TLSDemo

{

[STAThread]

static void Main(string[] args)

{

Threads threads = new Threads();

Thread createDataThread = new Thread(

new ThreadStart(threads.CreateDataThread));

createDataThread.Start();

Thread readDataThread = new Thread(

new ThreadStart(threads.ReadDataThread));

readDataThread.Start();

readDataThread.Join();

createDataThread.Resume();

}

class Threads

{

private const string SLOT_NAME = "temp slot";

public void CreateDataThread()

{

LocalDataStoreSlot slot =

Thread.AllocateNamedDataSlot(SLOT_NAME);

string data = "DATA";

Thread.SetData(slot, data);

Console.WriteLine("Thread1: writes data:({0}) into TLS,",

"then suspends", data);

Thread.CurrentThread.Suspend();

object oData = Thread.GetData(slot);

Console.WriteLine("Thread1: data after tampering: {0}",

oData);

}

public void ReadDataThread()

{

LocalDataStoreSlot slot =

Thread.GetNamedDataSlot(SLOT_NAME);

Thread.SetData(slot, "TAMPERED DATA");

Console.WriteLine("Thread2: tampers data in TLS, writes,

"{0}", "TAMPERED DATA");

}

Как работи примерът?

Нишката createDataThread създава наименован слот за данни и записва някакви примерни данни в него. Извикването на Suspend() позволява на readDataThread да започне да се изпълнява. Тя се опитва да запише нови данни в същия слот. Тъй като този слот обаче принадлежи към Thread Local Storage на първата нишка, опитът е неуспешен и резултатът е следният:

Thread-Relative Static Fields (статични полета, свързани с нишката)

Статичните полета, свързани с нишката донякъде наподобяват обикновените статични член-променливи в един клас. Те се декларират по аналогично начин и това, което ги отличава е, че са придружени от атрибута [ThreadStatic]. Всяка стартирана нишка ползва отделна инстанция на тази член-променлива.

Thread-Relative Static Fields – пример

За да илюстрираме работата с атрибута [ThreadStatic] ще използваме следния пример:

class ThreadStatic

{

[STAThread]

static void Main(string[] args)

{

for( int i=0; i<10; i++ )

{

ThreadStart threadDelegate = new ThreadStart(new

MyThread().DoTask);

Thread currentThread = new Thread(threadDelegate);

currentThread.Start();

}

class MyThread

{

// This initialization is executed in the static

// constructor, called by the main application thread

[ThreadStatic]

public static int abc = 42;

public void DoTask()

{

abc++;

Console.WriteLine("abc={0}", abc);

}

Когато този кратък код се изпълни, изходът е на пръв поглед странен:

Как работи примерът?

Тук член-променливата abc е именно thread-relative статично поле. Десетте стартирани нишки използват десет различни инстанции на abc. Инициализацията abc=42 обаче няма значение, защото конструкторът на MyThread се изпълнява в главната нишка. Член-променливата с атрибут [ThreadStatic] се инициализира отново при стартирането на нишката и нейна грижа е да го инициализира коректно.

Ако премахнем атрибута [ThreadStatic], това ще бъде една обикновена статична член-променлива, обща за всички стартирани нишки:

Неудобства при работата с нишки

Не трябва да се прекалява с употребата на нишки. Управлението на много нишки и превключването от една нишка към друга отнема време, понякога надвишаващо времето за изпълнението им. От тази гледна точка, за голям брой кратки операции е добре да се използва пул от нишки (thread pool), а не много на брой нишки, които изпълняват еднократно по една малка задача.

Паралелната работа на много нишки е също трудна за следене. Тя води и до необходимостта от синхронизация, която да предотврати повреждане на данните.

Проблеми при работа с общи данни

Работата с общи данни от няколко нишки едновременно крие в себе си много опасности, които трябва да бъдат предвидени и предотвратени чрез подходящи програмни техники. Типични такива опасности са повреждането на данни (race condition) и "мъртвата хватка" (deadlock).

Повреждане на данни

Данни, които са общи за две или повече нишки, лесно могат да бъдат повредени, ако достъпът до тях не е синхронизиран. Когато две нишки пишат едновременно в памет, заделена за някаква променлива, резултатите са непредвидими. Този проблем е известен като "повреждане на данни" или "състезание" (race condition).

Повреждане на данни – пример

За пример ще дадем един клас, който представлява банкова сметка. Когато две нишки едновременно теглят пари от тази банкова сметка, остатъкът в нея става некоректен.

class Bank

{

static void Main(string[] args)

{

Account acc = new Account();

acc.mBalance = 500;

Console.WriteLine("Account balance = {0}", acc.mBalance);

Thread user1 = new Thread( new ThreadStart

(acc.Withdraw100) );

Thread user2 = new Thread( new ThreadStart

(acc.Withdraw100) );

user1.Start();

user2.Start();

user1.Join();

user2.Join();

Console.WriteLine("Account balance = {0}", acc.mBalance);

}

class Account

{

public int mBalance;

public void Withdraw100()

{

int oldBalance = mBalance;

Console.WriteLine("Withdrawing 100...");

// Simulate some delay during the processing

Thread.Sleep(100);

int newBalance = oldBalance - 100;

mBalance = newBalance;

}

След изпълнението на програмата, остатъкът по сметката не е 300, а 400:

Резултатът е изненадващ, защото двете нишки едновременно променят една и съща член-променлива. Получената грешка е времезависима – ако приспим нишките за друг интервал от време, или пък не ги приспим изобщо, резултатът може и да е верен.

Мъртва хватка (deadlock)

Друг опасен синхронизационен проблем е т.нар. "мъртва хватка" (deadlock). Това е състояние, при което две нишки взаимно се чакат за освобождаване на заети от тях ресурси. Например нишка A използва ресурса X и би го освободила при възможност да заеме ресурс Y. Нишка B, от своя страна, използва Y и чака X. Получава се "увисване", при което нито една от двете нишки не може да продължи.

Типично за ситуацията "мъртва хватка" е, че не може да се получи, ако споделеният ресурс е само един. Ако ресурсите са няколко, "мъртвата хватка" може да се избегне, ако те се взимат в еднакъв ред от различните нишки. Например ако в предишния пример нишка А първо взима ресурса X, а след това Y и нишка B се опитва да вземе в същия ред първо ресурс X, а след това ресурс Y, не може да се получи безкрайно чакане. Или нишката ще вземе двата ресурса, или нишката B – според това коя е била първа.

Синхронизация

В края на предишната точка показахме до какво може да доведе едновременният достъп до общи ресурси. Целта на синхронизацията е това да не се допуска. Тук ще разгледаме някои стратегии за синхронизация.

Най-доброто решение за общите данни

В идеалния вариант, изобщо нямаме споделени данни. Ако данните в обектите са капсулирани така, че да не е нужно да бъдат споделяни между две и повече нишки, проблемите с общите данни автоматично отпадат. Понякога обаче е наложително да споделяме данни и в такъв случай трябва да използваме механизмите за синхронизация, които .NET Framework предлага.

Синхронизирани "пасажи" код (synchronized code regions)

Тук се синхронизират само отделни участъци от кода – тези, които са рискови. Критична секция наричаме участък от кода, до който не трябва да бъде допускан едновременен достъп. За гарантиране безопасен достъп до критична секция може да използваме ключовата дума lock или класа Monitor.

lock (obj)

{

// code

}

или

Monitor.Enter(obj);

try

{

// code

}

finally

{

Monitor.Exit(obj);

}

Обектът obj трябва да бъде от референтен тип (ако не е, се извършва опаковане, което ще доведе до безрезултатно заключване на различен новосъздаден обект при всяко влизане в секцията). На мястото на obj да често се ползва this или член-променлива, дефинирана специално за целта. В случаите, когато искаме да защитим статична член-променлива или критичната секция е в тялото на статичен метод, obj може да бъде typeof(class).

Работа с критични секции – пример

От главната нишка на програмата ще пуснем две други нишки, стартиращи от един и същ метод. Когато едната нишка започне изпълнение, другата ще чака, защото обработката на двете нишки е в критична секция и достъпът до нея е синхронизиран.

public class MonitorEnterExitDemo

{

private int mCounter = 0;

public void CriticalSection()

{

Monitor.Enter(this);

try

{

Console.WriteLine("Entering {0}.",

Thread.CurrentThread.Name);

for(int i = 1; i <= 5; i++)

{

mCounter++;

Console.WriteLine("{0}: counter={1}",

Thread.CurrentThread.Name, mCounter);

Thread.Sleep(500);

}

Console.WriteLine("Exiting {0}.",

Thread.CurrentThread.Name);

}

finally

{

Monitor.Exit(this);

}

public static void Main()

{

MonitorEnterExitDemo demo = new MonitorEnterExitDemo();

Thread thread1 = new Thread(new

ThreadStart(demo.CriticalSection));

thread1.Name = "Thread1";

thread1.Start();

Thread thread2 = new Thread(new

ThreadStart(demo.CriticalSection));

thread2.Name = "Thread2";

thread2.Start();

}

Когато изпълним програмата, виждаме, че втората нишка влиза в критичната си секция едва след като първата е приключила:

Как работи примерът?

Изразът Monitor.Enter(this) поставя началото на критичната секция. Нишката, която първа го изпълни (в случая, това е thread1), "заключва" кода след този ред до освобождаването на монитора с Monitor. Exit(this); във finally клаузата. Едва тогава, след като критичната секция е "отключена", другата нишка може да влезе в нея.

Същият ефект може да се постигне и с ключовата дума lock.

Ще оставим на читателя сам да направи сравнението при липса на синхронизация.

Методите Wait(…) и Pulse(…)

Wait(object) и Pulse(object) са два от важните методи на класа Monitor. Извикването на Monitor.Wait(object) освобождава монитора на посочения обект и блокира викащата нишка, докато не си върне монитора. Това блокиране трае до извикването на Monitor.Pulse(object) от друга нишка. При блокирането на нишката може да се укаже таймаут. Ако такъв няма, нишката може да остане блокирана завинаги, в случай, че Pulse(…) не бъде извикан. В този интервал от време, нишката стои в опашката на чакащи нишки.

Методът Monitor.Pulse(…) може да се извика само от текущия притежател на монитора на обекта – т.е. от критична секция. Нишката преминава в опашката на нишки, готови да се изпълняват и да вземат монитора.

Към тези два метода можем да причислим и Monitor.PulseAll(…), който има действие, аналогично на Pulse(…), но за цялата опашка от чакащи нишки.

Wait(…) и Pulse(…) – пример

Демонстрацията илюстрира синхронизация между нишки чрез заспиване и събуждане (Monitor.Wait(…) и Monitor.Pulse(…)). В примера се създават две нишки, всяка от които извършва някаква работа, събужда другата и заспива.

public class WaitPulse

{

private object mSync;

private string mName;

public WaitPulse(string aName, object aSync)

{

mName = aName;

mSync = aSync;

}

public void DoJob()

{

lock (mSync)

{

Console.WriteLine("{0}: Start", mName);

Console.WriteLine("{0}: Pulsing...", mName);

Monitor.Pulse(mSync);

for(int i = 1; i <= 3; i++)

{

Console.WriteLine("{0}: Waiting...", mName);

Monitor.Wait(mSync);

Console.WriteLine("{0}: WokeUp", mName);

Console.WriteLine("{0}: Do some work...", mName);

Thread.Sleep(1000);

Console.WriteLine("{0}: Pulsing...", mName);

Monitor.Pulse(mSync);

}

Console.WriteLine("{0}: Exiting", mName);

}

public class WaitPulseDemo

{

public static void Main(String[] args)

{

object sync = new object();

WaitPulse wp1 = new WaitPulse("WaitPulse1", sync);

Thread thread1 = new Thread(new ThreadStart(wp1.DoJob));

thread1.Start();

WaitPulse wp2 = new WaitPulse("WaitPulse2", sync);

Thread thread2 = new Thread(new ThreadStart(wp2.DoJob));

thread2.Start();

}

Как работи примерът?

При стартиране, създаваме обекта sync. Когато създаваме нишките, им предаваме този обект и синхронизацията се извършва по него. Всяка от нишките извиква Monitor.Pulse(mSync), с което събужда другата нишка, ако тя е заспала. След това, в цикъл, всяка от нишките заспива, докато не бъде събудена от другата, върши някаква работа и събужда другата.

В резултат, двете нишки се редуват – докато едната работи, другата спи.

Синхронизирани контексти (Synchronized Contexts)

Това е синхронизация на ниво клас. За целта, класът трябва да наследява ContextBoundObject. Обектите от такъв клас оперират в един контекста, който е част от домейна на приложението. Ако за такъв клас използваме атрибута SynchronizationAttribute, неговите методи са нишково обезопасени, т. е. два или повече метода не могат да бъдат изпълнявани едновременно от различни нишки. Статичните членове обаче не са предпазени.

Синхронизирането е на ниво клас – не можем да поддържаме синхронизация по отношение на някакъв участък от кода.

Синхронизиран контекст – пример

Класът CBO е наследник на ContextBoundObject и има атрибут [SynchronizationAttribute]. Два негови метода служат за тяло на общо 6 нишки. Единият метод е по-бърз от другия, като това не влияе върху синхронизацията.

class Starter

{

static void Main()

{

CBO syncClass = new CBO();

Console.WriteLine("Main thread starts 6 threads:\n" +

"3 doing Job1 and 3 doing Job2.\n\n" +

"Tasks should execute consequently.\n");

for (int i=0; i<6; i++)

{

Thread t;

if( i%2==0 )

t = new Thread( new ThreadStart(

syncClass.DoSomeTask1) );

else

t = new Thread( new ThreadStart(

syncClass.DoSomeTask2) );

t.Start();

}

[SynchronizationAttribute]

class CBO : ContextBoundObject

{

public void DoSomeTask1()

{

Console.WriteLine("Job1 started.");

Thread.Sleep(2000);

Console.WriteLine("Job1 finished.\n");

}

public void DoSomeTask2()

{

Console.WriteLine("Job2 started.");

Thread.Sleep(1500);

Console.WriteLine("Job2 finished.\n");

}

Резултатът е следният:

В даден момент, не повече от един метод на класа може да се изпълнява и нишките се изчакват една друга.

MethodImplAttribute

MethodImplAttribute е атрибут, позволяващ "заключване" на цял метод, независимо от това дали методът е статичен или не. Използва се по следния начин:

[MethodImpl(MethodImplOptions.Synchronized)]

public void DoSomeTask()

{

// Some code

}

По този начин може да синхронизираме достъпа до DoSomeTask(). Аналогичен ще бъде резултатът, ако използваме ключовата дума lock върху кода на целия метод.

Неуправлявана синхронизация – класът WaitHandle

Синхронизацията, която разгледахме до момента, беше управлявана синхронизация. Винаги, когато използваме ключовата дума lock, класа Monitor или атрибути за синхронизация, това е синхронизация, контролирана от CLR.

В тази точка ще слезем на малко по-ниско ниво, за да разгледаме неуправляваната синхронизация (unmanaged synchronization). При нея се използват обекти на операционната система.

Неуправляваната синхронизация в .NET Framework е представена от базовия клас WaitHandle и неговите наследници – Mutex, AutoResetEvent и ManualResetEvent. Обектите от тези класове са примитиви за синхронизация на операционната система. Методите на WaitHandle се използват за изчакването на събития. Синхронизацията се основава на "сигнализирането" на тези събития.

Добре е да се внимава с употребата на неуправлявана синхронизация. Независимо, че на моменти тя дава по-големи възможности от управляваната, нейната зависимост от операционната система прави преносимостта на кода по-трудна. Освен това, класът Monitor използва по-ефективно системните ресурси.

WaitHandle – по-важни методи

Ето някои от най-често използваните методи на класа WaitHandle:

- static bool WaitAny(WaitHandle[])

- static bool WaitAll(WaitHandle[])

- virtual bool WaitOne()

Трите изброени метода са предефинирани в класа WaitHandle, но за да обясним действието им ще се спрем само на този техен базов формат.

WaitAny(…) блокира текущата нишка до получаването на първия сигнал от масив от WaitHandle обекти, а WaitAll(…) – до получаване на сигнал от всички обекти. Тези методи са без аналог при управляваната синхронизация, напр. чрез класа Monitor.

За разлика от първите два метода, които са статични, WaitOne() е метод на инстанцията. Когато се предефинира в клас, наследник на WaitHandle, той блокира текущата нишка, докато текущия WaitHandle обект получи сигнал. В следващата точка ще демонстрираме употребата на този метод за класа Mutex.

Класът Mutex

Класът Mutex е наследник на WaitHandle и представлява "мутекс" - примитив за синхронизация на операционната система. Той наподобява Monitor, но не е свързан с обект. Самата дума "мутекс" произлиза от английския термин за взаимно изключване (mutual exclusion).

Когато една нишка придобие мутекса, друга може да го вземе едва след като първата го освободи. Всяка нишка може да поиска мутекса с Mutex.WaitOne() и след като приключи работата си, да го освободи с Mutex.ReleaseMutex(). Веднъж придобила мутекс чрез извикване на WaitOne(), нишката може да извика същия метод произволен брой пъти, като продължава нормалното си изпълнение. За да бъде освободен мутекса обаче, ReleaseMutex() трябва да бъде извикан същия брой пъти.

Методите WaitAll(…) и WaitAny(…), дефинирани в базовия клас WaitHandle, тук могат успешно да се прилагат.

Синхронизация с Mutex – пример

Следващият код решава познатата задача за синхронизиран достъп до дадена критична секция, но чрез Mutex обект.

class MutexMain

{

const int THREAD_COUNT = 5;

static void Main(string[] args)

{

Mutex commonMutex = new Mutex();

Thread[] demoThreads = new Thread[THREAD_COUNT];

for (int i=0; i<THREAD_COUNT; i++)

{

MutexThread mutexThread = new MutexThread(commonMutex);

demoThreads[i] = new Thread(

new ThreadStart(mutexThread.PerformSomeTask));

demoThreads[i].Start();

}

foreach (Thread thread in demoThreads)

{

thread.Join();

}

Console.WriteLine("Main Thread Exits");

}

class MutexThread

{

Mutex mMutex;

public MutexThread(Mutex aMutex)

{

mMutex = aMutex;

}

public void PerformSomeTask()

{

mMutex.WaitOne();

Thread.Sleep(200);

Console.WriteLine("\nStarting some job...");

for (int i=0; i<10; i++)

{

Thread.Sleep(100);

Console.Write("|");

}

Console.WriteLine("\nJob finished.");

mMutex.ReleaseMutex();

}

Как работи примерът?

На всички нишки, които създаваме в метода Main(…), подаваме един обект от клас Mutex. Така всички нишки от масива demoThreads работят с един и същ мутекс. Всички нишки имат за обработка метода PerformSomeTask(). Когато някоя от стартираните нишки изпълни реда mMutex.WaitOne();, тя получава мутекса ако е свободен, влиза в критичната секция, свършва някаква работа и освобождава мутекса с mMutex.ReleaseMutex(). Така се гарантира взаимното изключване.

Резултатът от изпълнението е следният:

Класовете AutoResetEvent и ManualResetEvent

Това са още два класа, които наследяват WaitHandle и представляват примитиви за синхронизация. Обектите от клас AutoResetEvent и ManualResetEvent са събития и могат да имат две състояния – сигнализирани и несигнализирани. Едно събитие може явно да се установи в сигнализирано състояние с метода Set() и в несигнализирано – с Reset().

AutoResetEvent обект, сигнализиран чрез Set(), сигнализира само първия чакащ манипулатор. След първия изпълнен WaitOne() от този обект, събитието се връща в несигнализирано състояние. Ако събитието обаче е от клас ManualResetEvent, то сигнализира всички чакащи манипулатори. Веднъж сигнализирано, то може да бъде върнато в несигнализирано състояние единствено с извикване на Reset().

AutoResetEvent и ManualResetEvent – пример

Със следващия пример ще демонстрираме работата с класовете AutoResetEvent и ManualResetEvent и ще покажем разликите при сигнализирането на събитията. Нека най-напред разгледаме случая, в който събитието е от тип AutoResetEvent.

class MainClass

{

const int THREADS_COUNT = 5;

static void Main()

{

AutoResetEvent evnt = new AutoResetEvent(false);

for (int i=0; i<THREADS_COUNT; i++)

{

OneWhoWaits oww = new OneWhoWaits(evnt, (i+1)*500);

Thread thread = new Thread(new

ThreadStart(oww.PerformSomeTask));

thread.Start();

}

Thread.Sleep(100);

for (int i=0; i<THREADS_COUNT; i++)

{

Console.WriteLine("\nPress [Enter] to signal the Reset"+

" Event.");

Console.ReadLine();

evnt.Set();

}

Console.WriteLine("\nMain thread finished.");

}

class OneWhoWaits

{

WaitHandle mWaitHandle;

int mWaitTime;

public OneWhoWaits(WaitHandle aWaitHandle, int aWaitTime)

{

mWaitHandle = aWaitHandle;

mWaitTime = aWaitTime;

}

public void PerformSomeTask()

{

Console.WriteLine("Thread {0} started and sleeps.",

Thread.CurrentThread.GetHashCode());

Thread.Sleep(mWaitTime);

Console.WriteLine("Thread {0} woke up and is now waiting.",

Thread.CurrentThread.GetHashCode());

mWaitHandle.WaitOne();

Console.WriteLine("Thread {0} was signaled and exits.",

Thread.CurrentThread.GetHashCode());

}

Как работи примерът?

Най-напред, създаваме синхронизационния обект evnt и го подаваме на петте нишки, които стартираме. Аргументът false в конструктора на evnt показва, че събитието е в несигнализирано състояние при създаването си. Стартираните нишки се блокират на реда mWaitHandle.WaitOne(); и чакат потребителя да натисне [Enter], с което да се сигнализира събитието. Тъй като събитието е от тип AutoResetEvent, с всяко натискане на [Enter] пропускаме по една нишка. След петото натискане, всички нишки приключват.

Нека сменим само типа на събитието, което създаваме:

ManualResetEvent evnt = new ManualResetEvent(false);

Сега първото натискане на [Enter] води до приключване на всички нишки – включително и тези, които още не са започнали да чакат. Това е така, защото след реда evnt.Set();, събитието никъде не се връща в несигнализирано състояние. ManualResetEvent събитието може да се върне в несигнализирано състояние само с Reset(), затова нека направим и тази промяна:

for (int i=0; i<THREADS_COUNT; i++)

{

Console.WriteLine("\nPress [Enter] to signal the Reset "+

"Event.");

Console.ReadLine();

evnt.Set();

// code added

Thread.Sleep(10);

evnt.Reset();

}

Сега натискането на [Enter] предизвиква пропускане само на нишките, които в този момент са чакащи – достигналите до реда mWaitHandle. WaitOne();. Тъй като след сигнализирането на събитието, го връщаме ръчно в несигнализирано състояние, за останалите нишки то вече е несигнализирано и те чакат ново натискане на [Enter].

Класът Interlocked

Понякога единственото, което ни трябва, е да увеличим или намалим дадена стойност или да разменим стойности по синхронизиран начин. Разбира се, можем за целта да използваме мутекси, но това до голяма степен ще усложни кода ни. За удовлетворяване на тези често срещани изисквания .NET Framework предоставя класа Interlocked. Той предлага няколко статични метода за атомарна работа с променливи. Атомарна наричаме всяка операция, която или се изпълнява цялата, или не се изпълнява изобщо.

Increment(…) и Decrement(…)

Методите Increment(…) и Decrement(…) служат съответно за увеличаване и намаляване на стойност. Te приемат единствен параметър от тип ref int или ref long и като резултат връщат стойността, получена след извършване на операцията.

int i = 2;

int newValue = Interlocked.Increment(ref i);

Debug.Assert(i == 3);

Debug.Assert(newValue == 3);

Ако увеличим променливата с i++, това не е атомарна операция – стойността на променливата се записва в регистър, стойността й се увеличава и се записва обратно в променливата, или общо три операции.

Exchange(…) и CompareExchange(…)

Методът Exchange(…) служи за размяна на стойности, докато CompareExchange(…) сравнява две променливи и ако са равни по стойност, указва нова стойност за едната. Двата метода имат по три версии, различаващи се само в типа на параметрите, с които оперират (int, float или object). Връщаният резултат е от тип, същия като типа на аргументите им.

Пример с CompareExchange(…)

Докато предназначението на метода Exchange(…) е ясно, то семантиката на CompareExchange(…) не е толкова проста и затова ще илюстрираме действието му с пример:

using System.Threading;

public class ThreadSafeTotalAccumulation

{

private int totalValue = 0;

public int AddToTotal(int valueToAdd)

{

int initialValue, computedValue;

{

initialValue = totalValue;

computedValue = initialValue + valueToAdd;

} while (initialValue != Interlocked.CompareExchange(

ref totalValue, computedValue, initialValue));

return computedValue;

}

Как работи примерът?

Класът ThreadSafeTotalAccumulation съдържа поле totalValue, към което искаме да добавим някаква стойност по нишково безопасен начин. Когато влезем в цикъла, запомняме старата сума в initialValue и пресмятаме новата в computedValue. CompareExchange(…) сравнява totalValue и initialValue. Ако не са равни, значи друга нишка е успяла да обнови общата сума по време на изпълнение на цикъла. Тогава CompareExchange(…) не обновява totalValue, а връща съдържанието на totalValue, което е различно от initialValue, и цикълът се повтаря. В момента на излизане от цикъла, computedValue е записан в totalValue. Връщаме computedValue, а не totalValue, защото totalValue може междувременно да бъде променена.

Класът Interlocked е полезен само в случаите, когато промяната на променливите минава винаги през него и никога не ги модифицираме директно.

Класически синхронизационни задачи

Случаите, в които две и повече нишки се конкурират за общи ресурси, често си приличат. Известни са няколко основни категории проблеми, представени от следните класически синхронизационни задачи

Задачата "Производител - потребител" (The Producer – Consumer Problem)

Две нишки, условно наречени "производител" и "потребител", споделят обща опашка от данни с някаква дължина. Производителят създава данни и ги прибавя към опашката. От своя страна, потребителят ги чете от нея. Проблемите, които възникват, са следните:

- Поради ограничения размер на опашката, производителят не трябва да се опитва да записва данни в нея, когато е пълна. Ако това е така, той чака, докато потребителят прочете някой от елементите и освободи място.

- Потребителят не трябва да се опитва да чете от празна опашка. В този случай той ще чака, докато производителят добави нов елемент.

Задачата е известна още под името "ограничен буфер" (bounded buffer). Нейният частен случай, в който дължината на опашката е безкрайна, е известна като "неограничен буфер" (unbounded buffer). Тогава отпада условието производителят да не пише в пълна опашка и решението се опростява.

Задачата "Производител - потребител" – примерно решение

В .NET Framework не е предоставен стандартен клас за решение на този проблем, но приложението на тази задача в практиката е голямо. Ще дадем примерно решение на проблема, което лесно позволява да бъде преизползвано при нужда:

using System;

using System.Collections;

using System.Threading;

public class SharedQueue

{

private static object[] mSharedQueue;

private static int mCurrentElementPointer = -1;

private static int mCapacity;

public SharedQueue(int aCapacity)

{

mSharedQueue = new object[aCapacity];

mCapacity = aCapacity;

}

public void Enqueue(object aObject)

{

while(true)

{

lock(this)

{

if(mCurrentElementPointer < mCapacity-1)

{

mCurrentElementPointer++;

mSharedQueue[mCurrentElementPointer] = aObject;

Monitor.Pulse(this);

return;

}

else

{

Monitor.Wait(this);

}

public object Dequeue()

{

while(true)

{

lock(this)

{

if(mCurrentElementPointer != -1)

{

object result= mSharedQueue[mCurrentElementPointer];

mCurrentElementPointer--;

Monitor.Pulse(this);

return result;

}

else

{

Monitor.Wait(this);

}

Как работи примерът?

Реализиран е случаят с ограничен буфер. Операциите добавяне и изваждане на елемент са синхронизирани и блокират съответно при препълнена или празна опашка.

Добавянето на елемент в опашката (вж. метода Enqueue(…)) е възможно само когато никой не я ползва в дадения момент и тя не е препълнена. Ако в момента опашката се ползва (т.е. е заключена), чакаме да бъде отключена. Това се осигурява от lock блока. След това, ако опашката не е препълнена, добавяме новия елемент в нея и викаме Monitor.Pulse(), за да събудим чакащите нишки, блокирали в метода Dequeue() (ако има такива). Ако опашката е препълнена, приспиваме с Monitor.Wait() текущата нишка. Тя ще бъде събудена от друга нишка, която успешно е изпълнила метода Dequeue() и е освободила място в опашката.

Изваждането на елемент от опашката работи абсолютно аналогично на добавянето.

Задачата "Четци и писачи" (The Readers-Writers Problem)

В тази задача имаме един или повече "писачи", които искат да пишат върху даден общ ресурс, например файл. Успоредно на тях, един или повече "четци" четат от същия ресурс. За да е коректен достъпът до общия ресурс, необходимо е да са спазени следващите условия (условия на Бернщайн):

- Произволен брой четци могат да имат едновременен достъп до ресурса – това няма как да породи синхронизационни проблеми, защото в този момент ресурсът не се променя.

- Ако на писач е предоставен достъп до ресурса, достъпът на всички останали трябва да бъде забранен – независимо дали четци или писачи.

- Нито един четец или писач не трябва да чака безкрайно дълго

.NET Framework предлага решение на тази задача - класът ReaderWriterLock. Критичният ресурс се заключва с методите AcquireReaderLock(…) и AcquireWriterLock(…), съответно за четец и писач. Освобождаването става с ReleaseReaderLock() и ReleaseWriterLock(). Свойствата IsReaderLockHeld и IsWriterLockHeld ни информират дали ресурсът е текущо заключен от четец или от писач.

Ето един примерен алгоритъм за това, как да използваме класа ReaderWriterLock.

class Resource

{

ReaderWriterLock rwLock = new ReaderWriterLock();

public void Read()

{

rwLock.AcquireReaderLock(Timeout.Infinite);

try

{

// Many can read, writers are blocked

}

finally

{

rwLock.ReleaseReaderLock();

}

public void Write()

{

rwLock.AcquireWriterLock(Timeout.Infinite);

try

{

// One can write, readers are blocked

}

finally

{

rwLock.ReleaseWriterLock();

}

Задачата "Обядващи философи" (The Dining Philosophers Problem)

В тази задача, няколко философа стоят около кръгла маса и всеки от тях извършва само 2 действия – храни се или мисли. За да започне даден философ да се храни, той се нуждае едновременно от двете вилици, които стоят вляво и вдясно от чинията му. Ако един философ вземе едната вилица, но не може да вземе в този момент и другата (защото тя е заета), той не може да започне да се храни докато не се сдобие и с нея. Има риск всеки философ да хване една от вилиците в даден момент и да чака безкрайно за другата. Това ще доведе до "мъртва хватка" (deadlock). Задачата е да се измисли алгоритъм за хранене на философите, при който не се получават "мъртви хватки".

Задачата "Обядващи философи" – решения

Едно примерно решение на проблема е да наредим вилиците и да изискваме философите да ги вземат в нарастващ ред. Нека имаме 5 философа обозначени с P1, P2, P3, P4, и P5, а вилиците да са номерирани с F1, F2, F3, F4, и F5. Първият философ (P1) ще вземе първата вилица (F1) преди да се посегне към втората (F2). Философите от P2 до P4 ще се държат аналогично, вземайки Fx преди Fx+1. Философът P5 обаче ще вземе F1 преди F5 и именно тази асиметрия ще предотврати "мъртва хватка". Имплементацията на това решение е тривиална.

Друго просто решение на проблема е да разгледаме масата като споделен ресурс и при започване на операцията "взимане на две вилици" да използваме заключване на масата с критична секция. Аналогично постъпваме и при операцията "връщане на две вилици". По този начин правим операциите "взимане на двете вилици" и "връщане на двете вилици" атомарни, а това означава, че не може да се получи "мъртва хватка".

Пул от нишки (ThreadPool)

През голям период от своето съществуване, нишката се намира в състояние ThreadState.WaitSleepJoin – очакваща случването на някакво събитие или приспана със Sleep(…). Понякога нишката се "събужда" за много кратки периоди, само за да провери дали е изпълнено някакво условие. Поддържането на много неактивни нишки е излишно и консумира ресурси.

Подходът на пула от нишки намалява натоварването при създаване и унищожаване на нишки. Група нишки, наречени работни нишки (worker threads), се създават в началото на многонишковото приложение и формират пул. Работните нишки са фиксиран брой – веднъж създадени, не се убиват и не се създават нови. При нова задача, пулът предоставя работна нишка за нейното изпълнение. След приключване на работата, нишката се връща в пула без да се унищожава. Механизмът е подходящ за много на брой задачи, които могат да се изпълняват паралелно. Задачите за изпълнение се нареждат в опашка и започват да се изпълняват при предоставена им работна нишка.

Един процес може да има само един пул от нишки, общ за всички домейни на приложението в процеса. Стандартно, пулът от нишки е ограничен на 25 нишки на процесор.

Предимства

Пулът от нишки преизползва нишките. Не се губи време за създаване и унищожаване на нишки.

Задачата, обслужвана от работните нишки, се освобождава от задължението да ги създава и контролира.

Увеличаването на производителността е не само по отношение на текущото приложение, но и по отношение на другите стартирани процеси. Постоянният брой на работните нишки позволява на операционната система да оптимизира кванта от време, предоставян на нишките от всички процеси.

Недостатъци

Пулът от нишки е неудобен, когато е нужна контролираща нишка. Всички работни нишки са равнопоставени.

Работните нишки не трябва да работят върху споделени данни. Ако има нужда от синхронизация, пулът не е добро решение, защото по своята същност е асинхронен.

Ако някоя от задачите отнема много време, тя може да забави останалите.

Ако дадена задача е в пула от нишки, тя не може да се премахне от него.

Класът ThreadPool

В .NET Framework, пулът от нишки е имплементиран в класа ThreadPool. Чрез метода QueueUserWorkItem(…) добавяме нова задача в опашката. Първото извикване на метода създава пула от нишки на процеса.

ThreadPool – пример

Ще дадем следния пример за добавяне на задачи в опашката на пула от нишки и тяхното изпълнение:

class ThreadPoolDemo

{

const int TASKS_COUNT = 100;

public static void LongTask(object aParam)

{

Console.WriteLine("Started: {0}.", aParam);

Thread.Sleep(500);

Console.WriteLine("Finished: {0}.", aParam);

}

static void Main()

{

Console.WriteLine("Press [Enter] to exit.");

for (int i=1; i<=TASKS_COUNT; i++)

{

string taskName = "Task" + i;

ThreadPool.QueueUserWorkItem(new

WaitCallback(LongTask), taskName);

}

Console.ReadLine();

}

Как работи примерът?

Най-напред, главната нишка на приложението добавя в пула 100 задачи. При добавянето, посочваме метод, който да се изпълни, като използваме делегата WaitCallback, намиращ се в пространството от имена System. Threading. Методът QueueUserWorkItem(…) позволява да подадем към обработката и допълнителен параметър, в случая – името на задачата.

Задачите се изпълняват асинхронно, по реда на постъпването им. В даден момент се изпълняват по няколко задачи, като точният им брой се определя от броя на текущо свободните работни нишки.

Резултатът от изпълнението изглежда така:

Методът ThreadPool.RegisterWaitForSingleObject()

Можем да използваме този метод, когато искаме пула от нишки да чака за някакво събитие. Методът регистрира делегат. Методът, свързан с делегата, се изпълнява както при сигнализирането на това събитие, така и след изтичането на зададен таймаут.

RegisterWaitForSingleObject() – пример

Да разгледаме един пример за използването на метода ThreadPool. RegisterWaitForSingleObject():

static void Main()

{

AutoResetEvent ev = new AutoResetEvent(false);

object param = "some param";

RegisteredWaitHandle waitHandle =

ThreadPool.RegisterWaitForSingleObject(

ev, new WaitOrTimerCallback(WaitProc), param, 1000,

false );

Console.WriteLine("Press [Enter] to signal the wait handle.");

Console.ReadLine();

Console.WriteLine("Main thread signals.");

ev.Set();

Console.WriteLine("Press [Enter] to continue.");

Console.ReadLine();

Console.WriteLine("Main thread unregisters.");

waitHandle.Unregister(ev);

Console.WriteLine("Press [Enter] to exit.");

Console.ReadLine();

}

public static void WaitProc(object aState, bool aTimedOut)

{

string cause = aTimedOut ? "TIMED OUT" : "SIGNALLED";

Console.WriteLine("WaitProc executes; cause = {0}", cause);

}

Как работи примерът?

Подобно на метода QueueUserWorkItem(…), RegisterWaitForSingleObject(…) създава пула от нишки при своето извикване. Най-напред, посочваме събитието, което чакаме – това е ev от тип AutoResetEvent. Като използваме делегата WaitOrTimerCallback, посочваме метода WaitProc(…), който ще се изпълнява при сигнализиране на събитието. Към метода WaitProc(…) можем да подадем произволен параметър – обектът aState, на който преди това сме задали стойност "some param". Таймаутът, през който ще се изпълнява метода, е една секунда. Последният параметър определя дали метода да остане регистриран за събитието след първото си изпълнение, дали да се изпълнява на всяка сигнализация на събитието и на всеки изтекъл таймаут. Тъй като стойността му е false, методът няма автоматично да бъде дерегистриран след първото си изпълнение.

От този момент нататък, методът започва да се изпълнява на всяка секунда поради изтекъл таймаут. Натискането на [Enter] води до сигнализиране на събитието и еднократно изпълнение на WaitProc(…), но вече aTimedOut има стойност false. Изпълненията по изтекъл таймаут продължават до достигането на waitHandle.Unregister(ev);. Дерегистрирането става чрез референцията waitHandle, върната при регистрирането.

Интерфейсът ISynchronizeInvoke

Когато код, изпълняван в нишката T1, извика метод на обект, този метод обикновено се изпълнява синхронно в същата нишка Т1. Понякога обаче се налага изпълнението винаги да протича в нишката, където е създаден обекта (нека я обозначим с T2). Типичен пример за такава необходимост са класовете за форми и контроли в .NET Windows Forms, които трябва винаги да обработват съобщенията в същата нишка, в която са били създадени. За да се справи с подобни случаи, .NET Framework предоставя интерфейса System.ComponentModel.ISynchronizeInvoke:

public interface ISynchronizeInvoke

{

object Invoke(Delegate method, object[] args);

IAsyncResult BeginInvoke(Delegate method, object[] args);

object EndInvoke(IAsyncResult result);

bool InvokeRequired {get;}

}

Използване на ISynchronizeInvoke

ISynchronizeInvoke предоставя стандартен механизъм за извикване на методи на обекти, живеещи на други нишки. Нека един обект да имплементира ISynchronizeInvoke и клиентски код на нишка T1 да извика Invoke(…) върху този обект. Това ще доведе до следната последователност от действия:

1. Блокиране на извикващата нишка T1.

2. Маршализация на извикването до нишката T2.

3. Изпълнение върху нишката T2.

4. Маршализация на върнатите стойности до нишката T1.

5. Връщане на контрола на нишката T1.

Invoke(…) приема делегат, съответен на метода, който ще бъде изпълнен на T2, и масив от обекти като параметри.

Използване на ISynchronizeInvoke – пример

Ще дадем един пример, в който клас за калкулатор имплементира ISynchronizeInvoke и предоставя Add(…) метод за събиране на две числа. В кода сме пропуснали същинската реализация на методите на ISynchronizeInvoke, а ще концентрираме вниманието си върху начина на ползването на класа в клиентски код. Ето все пак как изглежда скелета на класа Calculator.

public class Calculator : ISynchronizeInvoke

{

public int Add(int arg1, int arg2)

{

int threadID = Thread.CurrentThread.GetHashCode();

Console.WriteLine("Callback thread ID is " + threadID);

return arg1 + arg2;

}

// ISynchronizeInvoke implementation here ...

}

Ето как се използва класа Calculator:

public delegate int AddDelegate(int arg1, int arg2);

public void CalculatorInvoke()

{

int threadID = Thread.CurrentThread.GetHashCode();

Console.WriteLine("Client thread ID is " + threadID);

Calculator calc = new Calculator();

AddDelegate addDelegate = new AddDelegate(calc.Add);

object[] arr = new object[] {3,4};

int sum = (int) calc.Invoke(addDelegate,arr);

Debug.Assert(sum == 7);

}

Един възможен изход, който можем да получим, е следният:

Callback thread ID is 29

Client thread ID is 30

Как работи примерът?

Тъй като обработката се изпълнява на нишка, различна от тази на клиентския код, можем да извършим асинхронно извикване чрез методите BeginInvoke(…) и EndInvoke(…). Асинхронният механизъм на работа е описан подробно по-надолу в темата.

Свойството InvokeRequired показва дали клиентската нишка е същата като тази, на която трябва да се изпълни метода на обекта. Ако е същата (т.е. InvokeRequired е равно на false), методът може да бъде извикан директно без механизма на ISynchronizeInvoke.

Windows Forms и ISynchronizeInvoke

Базовите класове в Windows Forms използват ISynchronizeInvoke. Всеки клас наследник на Control разчита на Windows съобщения и на опашката от събития, където те биват обработвани в безкраен цикъл. Но съобщенията за даден прозорец се доставят само до нишката, където е бил създаден. Затова, в общия случай, достъпът до Windows Forms класове от друга нишка трябва да става изключително и само през методите на ISynchronizeInvoke.

Таймери

Често в приложенията, които разработваме, възниква необходимост от изпълняване на задачи през регулярни времеви интервали. Таймерите предоставят такава услуга. Те са обекти, които известяват приложението при изтичане на предварително зададен интервал от време. Таймерите са полезни в редица сценарии, например, когато искаме да обновяваме периодично потребителския интерфейс с актуална информация за статуса на някаква задача или да проверяваме състоянието на променящи се данни.

Такава услуга изглежда на пръв поглед лесна за имплементация. Можем да използваме работна нишка, която заспива за определено време и после известява за събуждането си. Но трябва да реализираме и много други функции: за начало и край на отброяване на времето, за управление на работната нишка, за промяна на интервала, за задаване на функция за обратно извикване.

.NET Framework ни предоставя наготово три различни решения за този проблем. Ще разгледаме кога е удачно да използваме всеки един от класовете, които ще разгледаме.

System.Timers.Timer

Класът System.Timers.Timer има следната дефиниция:

public class Timer

{

public Timer();

public Timer(double interval);

// Properties

public bool AutoReset{get; set; }

public bool Enabled{get; set; }

public double Interval{get; set;}

public ISynchronizeInvoke SynchronizingObject { get; set; }

//Events

public event ElapsedEventHandler Elapsed;

// Methods

public void Close();

public void Start();

public void Stop();

/* Other members */

}

Класът предоставя събитие за изтичане на времевия интервал Elapsed, което е делегат от тип ElapsedEventHandler, дефиниран като:

public delegate void ElapsedEventHandler(

object sender, ElapsedEventArgs e);

При изтичане на интервала, указан в свойството Interval, таймерът от тип System.Timers.Timer ще извика записалите се за събитието методи, използвайки нишка от пула. Ако използваме един и същ метод за получаване на събития от няколко таймера, чрез аргумента sender можем да ги разграничим. Класът ElapsedEventArgs чрез свойството DateTime SignalTime ни предоставя точното време, когато е бил извикван метода.

За стартиране и спиране на известяването, можем да извикаме съответно Start() и Stop() методите. Свойството Enabled ни позволява да инструктираме таймера да игнорира събитието Elapsed. Това прави Enabled функционално еквивалентно на съответните Start() и Stop() методи. Когато приключим с таймера, трябва да извикаме Close(), за да освободим съответните системни ресурси.

System.Timers.Timer – пример

Ето пример за употребата на System.Timers.Timer:

using System;

using System.Timers;

using System.Threading;

class SystemTimerClient

{

System.Timers.Timer mTimer;

int mCounter = 0;

public SystemTimerClient()

{

mTimer = new System.Timers.Timer();

mTimer.Interval = 1000; // One second

mTimer.Elapsed += new ElapsedEventHandler(OnTick);

mTimer.Start();

//Can block, because the Timer uses thread from thread pool

Thread.Sleep(4000);

mTimer.Stop();

mTimer.Close();

}

private void OnTick(object source, ElapsedEventArgs e)

{

string tickTime = e.SignalTime.ToLongTimeString();

mCounter++;

Console.WriteLine(mCounter.ToString() + " " + tickTime);

}

private static void Main()

{

SystemTimerClient obj = new SystemTimerClient();

}

Резултатът от изпълнението на програмата е:

1 16:13:31

2 16:13:32

3 16:13:33

Как работи примерът?

Тъй като методът, който е обработчик на събитието за изтичане на интервал, се изпълнява в отделна нишка, трябва да осигурим синхронизиран достъп до член-променливите на обекта.

Свойството SynchronizingObject ни позволява да укажем обект, имплементиращ ISynchronizeInvoke. Той ще бъде използван от таймера за изпълнението на функцията за обратно извикване в определена нишка, вместо в нишка, принадлежаща на пула. Това е удобно, примерно, когато имаме таймер от тип System.Timers.Timer в клас, наследник на Windows.Forms.Form. Ако укажем самата форма на свойството SynchronizingObject, то методът обработчик на Elapsed ще се изпълни в основната нишка на потребителския интерфейс, където безопасно можем да променяме свойствата на формата и контролите й.

Visual Studio .NET има вградена поддръжка за System.Timers.Timer в дизайнера си. Можем директно да привлачим такъв обект от раздела компоненти върху Windows форма, ASP.NET форма или уеб услуга и да му укажем съответните свойства. В случая на Windows Forms, дизайнерът на VS.NET автоматично указва свойството SynchronizingObject на инстанцията на самата форма.

System.Threading.Timer

Пространството от имена System.Threading съдържа друг клас за таймер, който е със следната дефиниция:

public sealed class Timer : MarshalByRefObject, IDisposable

{

public Timer(TimerCallback callback,

object state, long dueTime, long period);

/* More overloaded constructors */

public bool Change(int dueTime, int period);

/* More overloaded Change() */

public virtual void Dispose();

}

System.Threading.Timer прилича на System.Timers.Timer и също използва пула с нишки. Основната разлика е, че той позволява малко по-разширен контрол – може да указваме кога таймера да започне да отброява, както и да предаваме всякаква информация на метода за обратни извиквания чрез обект от произволен тип. За да ползваме System.Threading.Timer, трябва в конструктора му да подадем делегат от тип TimerCallback, дефиниран като:

public delegate void TimerCallback(object state);

При всяко изтичане на времевия интервал, ще бъдат извиквани методите в този делегат. Обикновено като обект за състояние има полза да подаваме създателя на таймера, за да можем да използваме същия метод за обратни извиквания за обработка на събития от множество таймери. Другият параметър в конструктора на таймера е времевият интервал. Той може и да бъде променен впоследствие с извикване на Change(…) метода.

System.Threading.Timer не предлага удобен начин за стартиране и спиране. Неговата работа започва веднага след конструирането му (по-точно след изтичането на подаденото стартово време) и прекъсването му става само чрез Dispose(). Ако искаме да го рестартираме трябва да създадем нов обект.

System.Threading.Timer – пример

Ето един пример за употребата на System.Threading. Timer:

using System;

using System.Threading;

class ThreadingTimerClient

{

private Timer mTimer;

private int mCounter = 0;

public ThreadingTimerClient()

{

Start();

Thread.Sleep(4000);

Stop();

}

private void Start()

{

TimerCallback callBack = new TimerCallback(OnTick);

mTimer = new Timer(callBack, null, 0, 1000);

}

private void Stop()

{

mTimer.Dispose();

mTimer = null;

}

private void OnTick(object state)

{

mCounter++;

Console.WriteLine(mCounter.ToString());

}

private static void Main()

{

ThreadingTimerClient obj = new ThreadingTimerClient();

}

Резултатът от изпълнението на програмата е:

System.Windows.Forms.Timer

Пространството от имена System.Windows.Forms съдържа още един клас за таймер, който е със следната дефиниция:

public class Timer : Component, IComponent, Idisposable

{

public Timer();

public bool Enabled{virtual get ; virtual set;}

public int Interval {get; set;}

public event EventHandler Tick;

public void Start();

public void Stop();

}

Въпреки, че методите на System.Windows.Forms.Timer много приличат на тези на System.Timers.Timer, то System.Windows.Forms.Timer не използва пула с нишки за обратните извиквания към Windows Forms приложението. Вместо това, през определено време той пуска Windows съобщението WM_TIMER в опашката за съобщения на текущата нишка.

Използването на System.Windows.Forms.Timer се различава от употребата на System.Timers.Timer, само по сигнатурата на делегата за обратни извиквания, който в случая е стандартният EventHandler.

VS.NET има вградена поддръжка за System.Windows.Forms.Timer в дизайнера си. Можем директно да привлачим такъв обект от раздела Windows Forms върху Windows форма.

Тъй като при Windows Forms таймерите всички функции за обратни извиквания се изпълняват на главната нишка за потребителския интерфейс, то няма нужда от допълнителна синхронизация. Това обаче може да е проблем, защото при времеотнемащи операции приложението няма да може да отговаря бързо.

Как да изберем таймер?

Ако разработваме Windows Forms приложение, обикновено е най-лесно да използваме System.Windows.Forms.Timer. В повечето други случаи е по-удачно да ползваме System.Timers.Timer. Методите му изглеждат по-интуитивни и по-удобни от тези на System.Threading.Timer.

Volatile полета

Ако кодът ни използва публични полета, то оптимизациите, които извършва компилаторът, могат да доведат до неочаквани проблеми. Ако стойността на такава променлива се прочита няколко пъти, компилаторът може да я кешира при първото четене във временна локална променлива, вместо да осъществява достъп до нея през обекта, на когото принадлежи. Да разгледаме следния пример:

class MyClass

{

public int Number;

public static void Main()

{

MyClass obj = new MyClass();

int num1 = obj.Number;

int num2 = obj.Number; //Compiler may use cached value here

}

Оптимизациите при компилация могат да доведат до подобрена производителност, особено в цикли. Проблемът е, че ако настъпи превключване на активната нишка след инициализацията на num1 и преди тази на num2, и друга нишка промени стойността на Number, то num2 ще съдържа старата кеширана стойност.

Ако искаме да използваме такива публични полета (а по-препоръчително е използването на свойства) без да синхронизираме изрично достъпа до тях, можем да се възползваме от volatile полетата, които се поддържат от компилатора на C#. Те се дефинират с ключовата дума volatile:

public volatile int Number;

При volatile полета, компилаторът не кешира стойността им, а винаги я прочита наново. Във Visual Basic.NET няма еквивалент на C# ключовата дума volatile. Препоръчваме вместо да се ползват volatile полета, да си заключваме изрично обекта или полетата, за да гарантираме безопасен достъп до тях.

Асинхронни извиквания

Асинхронните извиквания са мощен механизъм за паралелно изпълнение на няколко задачи, при който не е необходимо изрично да се създава нова нишка за всяка задача.

Какво е асинхронно извикване?

По подразбиране методите в кода на програмата се изпълняват синхронно, тоест изпълнението преминава на следващия оператор чак след като приключи текущият метод. При асинхронното извикване не се изчаква края на изпълнението на текущия оператор, а веднага се преминава на следващия. Обработката на асинхронното извикване се извършва в отделна нишка, която обикновено е от стандартния пул с нишки.

Къде се ползва асинхронно извикване?

В .NET Framework широко се използват асинхронни извиквания при вход-изход от файлови и други потоци, при мрежови операции с HTTP и TCP, при отдалечено извикване с Remoting, при ASP.NET XML уеб услуги и други. Асинхронното програмиране се реализира лесно в нашия код с помощта на делегати. Като алтернатива можем и сами да предоставим явен асинхронен интерфейс за нашите класове, както ще видим малко по-късно.

Асинхронно извикване чрез делегат

Делегатите предоставят възможност за лесно асинхронно извикване на синхронни методи. Трябва само да създадем делегат със сигнатура, съответна на метода и можем да използваме функциите за започване на асинхронно извикване: BeginInvoke(…) и за изчакване на получаване на резултата: EndInvoke(…).

Асинхронно извикване чрез делегат – пример

Можем да илюстрираме казаното с прост пример, описващ асинхронно сумиране на две цели числа:

using System;

using System.Threading;

class AsyncCallDemo

{

public delegate int SumDelegate(int a, int b);

public int Sum(int a, int b)

{

Thread.Sleep(3000);

return a + b;

}

static void Main()

{

SumDelegate asyncCall = new SumDelegate(

new AsyncCallDemo().Sum);

Console.WriteLine("Starting method async.");

IAsyncResult status = asyncCall.BeginInvoke(5, 6, null,

null);

Console.WriteLine("Async method is now working...");

Console.WriteLine("Calling EndInvoke()...");

Console.WriteLine("It will block until method finishes.");

int result = asyncCall.EndInvoke(status);

Console.WriteLine("EndInvoke() returned.");

Console.WriteLine("Result = {0}", result);

}

Като резултат от изпълнението, ще получим следния изход:

Starting method async.

Async method is now working...

Calling EndInvoke()...

It will block until method is finished.

EndInvoke() returned.

Result = 11

В метода Sum(…) сме сложили реда Thread.Sleep(3000) и затова след съобщението "It will block until method is finished." се получава близо 3-секундно забавяне. Извикването на EndInvoke(…) блокира изпълнението на текуща нишка, докато не приключи съответното асинхронно извикване.

Модел за асинхронно програмиране

Ползването на делегати за асинхронно извикване е удобно, защото не изисква писане на много код. Има обаче случаи, в които се налага изрично да имплементираме асинхронно извикване на метод. Това е необходимо, когато бързодействието е критично (използването на делегати може да е тежко) или ако методът трябва да се извиква само асинхронно. В такива случаи се препоръчва следването на утвърдения в .NET Framework модел за асинхронни извиквания, с който ще се запознаем сега.

Сигнатура на методите за асинхронни извиквания

Нека да предоставим асинхронната версия на функцията Sum(…), която сумира две целочислени числа. В .NET Framework методите предназначени за асинхронно извикване използват нотацията BeginXXXXX(…) и EndXXXXX(…), където XXXXX е синхронната версия на метода. В случая трябва да дефинираме BeginSum(…) и EndSum(…), за да направим стандартна асинхронна версия на метода Sum(…):

IAsyncResult BeginSum(int a, int b,

AsyncCallback requestCallback,

object stateObject

AsyncCallback e делегат към метод, който да се извика след приключване изпълнението на асинхронното извикване. Ако подадем null, няма да се изпълни нищо след завършването.

int EndSum(IAsyncResult ar);

На блокиращия метод EndSum(…) му се подава IAsyncResult, върнат като резултат от BeginSum(…) и така се изчаква приключването на работата на асинхронния метод.

Интерфейсът IAsyncResult

Ето какви свойства предоставя интерфейсът IAsyncResult:

interface IAsyncResult

{

object AsyncState {get;}

WaitHandle AsyncWaitHandle {get;}

bool CompletedSynchronously {get;}

bool IsCompleted {get;}

}

AsyncState връща същия обект, подаден като stateObject на BeginSum(). Това е начин за следене на статуса на работа и само асинхронно извикваният метод трябва да го променя.

AsyncWaitHandle се използва като параметър на методите WaitAll(…), WaitOne() или WaitAny(…) на класа WaitHandle за изчакване приключването на асинхронния метод.

CompletedSynchronously връща true, ако асинхронният метод е приключил бързо работа, още преди края на извикването на BeginXXXXX(…).

IsCompleted връща true ако асинхронният метод е приключил своята работа. Чрез механизма "polling" можем през определено време да проверяваме истинността на IsCompleted, докато върне true.

Проверка за приключване на асинхронното извикване

Има четири начина да проверим дали е приключил един асинхронен метод

- Чрез механизма "polling" проверяваме IAsyncResult.IsCompleted през определено време.

- Чрез някои от методите за синхронизация на WaitHandle с параметър свойството IAsyncResult.AsyncWaitHandle. Можем и да зададем таймаут, за да не се чака безкрайно дълго.

- Чрез извикване на EndXXXXX(…), който блокира изпълнението, докато асинхронният метод не свърши работата си.

- Чрез подаване на метод за обратно извикване на BeginXXXXX(…) през делегата AsyncCallback, който приема единствен параметър от тип IAsyncResult. Подаденият метод ще бъде извикван, когато асинхронният метод приключи работа. Имаме достъп до резултата чрез свойството AsyncState.

Изчакване на асинхронна операция – няколко примера

Ще демонстрираме изброените подходи с един пример, в който асинхронно четем данни от файл. Първо ще разгледаме някои общи променливи и методи на класа FileReaderDemo, а после поотделно функциите, реализиращи всеки един от подходите:

using System;

using System.IO;

using System.Text;

using System.Threading;

internal class FileReaderDemo

{

private const string FILE_NAME = "data.txt";

private const int READ_BUF_SIZE = 8192;

private const int WAIT_TIMEOUT = 50;

private Stream GetFileStream(string aFileName)

{

FileStream stream =

new FileStream(

aFileName, FileMode.Open,

FileAccess.Read, FileShare.Read,

READ_BUF_SIZE, true);

return stream;

}

...

}

Асинхронно четене с polling:

public void AsynchronousPollReadFile()

{

Stream stream = GetFileStream(FILE_NAME);

byte[] buf = new byte[READ_BUF_SIZE];

IAsyncResult readResult = stream.BeginRead(

buf, 0, buf.Length, null, null);

Console.Write("Asynchronous Poll Read");

while (!readResult.IsCompleted)

{

Thread.Sleep(WAIT_TIMEOUT);

Console.Write(".");

}

Console.WriteLine();

using (stream)

{

int bytesRead = stream.EndRead(readResult);

string data = Encoding.ASCII.GetString(buf, 0, bytesRead);

Console.WriteLine("\tCount of bytes: {0}", bytesRead);

Console.WriteLine("\tData: {0}\n", data);

}

Асинхронно четене с WaitHandle:

public void AsynchronousWaitReadFile()

{

Stream stream = GetFileStream(FILE_NAME);

byte[] buf = new byte[READ_BUF_SIZE];

IAsyncResult readResult = stream.BeginRead(

buf, 0, buf.Length, null, null);

Console.Write("Asynchronous Wait Read");

bool finished;

{

finished = readResult.AsyncWaitHandle.

WaitOne(WAIT_TIMEOUT, false);

Console.Write(".");

} while (! finished);

Console.WriteLine();

using (stream)

{

int bytesRead = stream.EndRead(readResult);

string data = Encoding.ASCII.GetString(buf, 0, bytesRead);

Console.WriteLine("\tCount of bytes: {0}", bytesRead);

Console.WriteLine("\tData: {0}\n", data);

}

Асинхронно четене с EndRead(…):

public void AsynchronousEndReadFile()

{

Stream stream = GetFileStream(FILE_NAME);

using (stream)

{

byte[] buf = new byte[READ_BUF_SIZE];

IAsyncResult readResult = stream.BeginRead(

buf, 0, buf.Length, null, null);

int bytesRead = stream.EndRead(readResult);


Национална академия по разработка на софтуер
Лекторите » *Светлин Наков* е автор на десетки технически публикации и няколко книги, свързани с разработката на софтуер, заради което е търсен лектор и консултант. Той е разработчик с дългогодишен опит, работил по разнообразни проекти, реализирани с различни технологии (.NET, Java, Oracle, PKI и др.) и преподавател по съвременни софтуерни технологии в СУ "Св. Климент Охридски". През 2004 г. е носител на наградата "Джон Атанасов" на президента на България Георги Първанов. Светлин Наков ръководи обучението по Java технологии в Академията. » *Мартин Кулов* е софтуерен инженер и консултант с дългогодишен опит в изграждането на решения с платформите на Microsoft. Мартин е опитен инструктор и сертифициран от Майкрософт разработчик по програмите MCSD, MCSD.NET, MCPD и MVP и международен лектор в световната организация на .NET потребителските групи INETA. Мартин Кулов ръководи обучението по .NET технологии в Академията.	Академията » Национална академия по разработка на софтуер (НАРС) е център за професионално обучение на софтуерни специалисти. » НАРС провежда БЕЗПЛАТНО курсове по разработка на софтуер и съвременни софтуерни технологии в София и други градове. » Предлагани специалности: § Въведение в програмирането (с езиците C# и Java) § Core .NET Developer § Core Java Developer » Качествено обучение с много практически проекти и индивидуално внимание за всеки. » Гарантирана работа! Трудов договор при постъпване в Академията. » БЕЗПЛАТНО! Учите безплатно във въведителните курсове и по стипендии от работодателите в следващите нива.
http://academy.devbg.org


Национална академия по разработка на софтуер
Лекторите » *Светлин Наков* е автор на десетки технически публикации и няколко книги, свързани с разработката на софтуер, заради което е търсен лектор и консултант. Той е разработчик с дългогодишен опит, работил по разнообразни проекти, реализирани с различни технологии (.NET, Java, Oracle, PKI и др.) и преподавател по съвременни софтуерни технологии в СУ "Св. Климент Охридски". През 2004 г. е носител на наградата "Джон Атанасов" на президента на България Георги Първанов. Светлин Наков ръководи обучението по Java технологии в Академията. » *Мартин Кулов* е софтуерен инженер и консултант с дългогодишен опит в изграждането на решения с платформите на Microsoft. Мартин е опитен инструктор и сертифициран от Майкрософт разработчик по програмите MCSD, MCSD.NET, MCPD и MVP и международен лектор в световната организация на .NET потребителските групи INETA. Мартин Кулов ръководи обучението по .NET технологии в Академията.	Академията » Национална академия по разработка на софтуер (НАРС) е център за професионално обучение на софтуерни специалисти. » НАРС провежда БЕЗПЛАТНО курсове по разработка на софтуер и съвременни софтуерни технологии в София и други градове. » Предлагани специалности: § Въведение в програмирането (с езиците C# и Java) § Core .NET Developer § Core Java Developer » Качествено обучение с много практически проекти и индивидуално внимание за всеки. » Гарантирана работа! Трудов договор при постъпване в Академията. » БЕЗПЛАТНО! Учите безплатно във въведителните курсове и по стипендии от работодателите в следващите нива.
http://academy.devbg.org


Национална академия по разработка на софтуер
Лекторите » *Светлин Наков* е автор на десетки технически публикации и няколко книги, свързани с разработката на софтуер, заради което е търсен лектор и консултант. Той е разработчик с дългогодишен опит, работил по разнообразни проекти, реализирани с различни технологии (.NET, Java, Oracle, PKI и др.) и преподавател по съвременни софтуерни технологии в СУ "Св. Климент Охридски". През 2004 г. е носител на наградата "Джон Атанасов" на президента на България Георги Първанов. Светлин Наков ръководи обучението по Java технологии в Академията. » *Мартин Кулов* е софтуерен инженер и консултант с дългогодишен опит в изграждането на решения с платформите на Microsoft. Мартин е опитен инструктор и сертифициран от Майкрософт разработчик по програмите MCSD, MCSD.NET, MCPD и MVP и международен лектор в световната организация на .NET потребителските групи INETA. Мартин Кулов ръководи обучението по .NET технологии в Академията.	Академията » Национална академия по разработка на софтуер (НАРС) е център за професионално обучение на софтуерни специалисти. » НАРС провежда БЕЗПЛАТНО курсове по разработка на софтуер и съвременни софтуерни технологии в София и други градове. » Предлагани специалности: § Въведение в програмирането (с езиците C# и Java) § Core .NET Developer § Core Java Developer » Качествено обучение с много практически проекти и индивидуално внимание за всеки. » Гарантирана работа! Трудов договор при постъпване в Академията. » БЕЗПЛАТНО! Учите безплатно във въведителните курсове и по стипендии от работодателите в следващите нива.
http://academy.devbg.org