Aplikacje WWW w ASP.NET 2.0

ASP.NET to chyba najwygodniejszy sposób tworzenia serwisów intra- i internetowych. Programista otrzymuje bogatą kolekcję gotowych kontrolek, platforma zapewnia dużą stabilność działania aplikacji i mechanizmy do utrzymywania sesji użytkowników nawet w trakcie aktualizowania aplikacji, a Master Pages pozwalają zachować spójny wygląd stron.

ASP.NET to chyba najwygodniejszy sposób tworzenia serwisów intra- i internetowych. Programista otrzymuje bogatą kolekcję gotowych kontrolek, platforma zapewnia dużą stabilność działania aplikacji i mechanizmy do utrzymywania sesji użytkowników nawet w trakcie aktualizowania aplikacji, a Master Pages pozwalają zachować spójny wygląd stron.

ASP.NET zyskało bardzo dużą popularność dzięki dużej szybkości działania, wygodzie programisty i łatwemu "łączeniu" z zapleczem serwerowym - bazami danych, komponentami Enterprise Services (COM+) czy usługami WWW . Równocześnie nowa technologia - dzięki koncepcji "kontrolek serwerowych" - bardzo uprościła i uporządkowała tworzenie aplikacji WWW, w dużym stopniu eliminując żmudne generowanie kodu HTML, znane korzystającym z innych narzędzi do tworzenia stron WWW.

ASP.NET 2.0 to najnowsza wersja pakietu, wprowadzana wraz z nowym VisualStudio.NET.

Osoby, które planują migrację aplikacji z wersji 1.1 na pewno ucieszy wiadomość, że stare aplikacje bez problemu działają w nowym .NET. Ale jeżeli zechcemy je rozwijać w nowym środowisku, zetkniemy się z kilkoma nowymi cechami IDE.

Najważniejsza (i najbardziej upraszczającą życie) modyfikacja to zmiana roli projektu. W ASP.NET 2.0 jest to po prostu folder z pewną strukturą i plikami składowymi. Jednak należy pamiętać, że z tego powodu znacznie ważniejsze stały się dyrektywy @Page i konfiguracja w Web.config, co razem pozwala określić, jak dana strona będzie kompilowana w ramach aplikacji ASP.NET (w 1.1 część tych informacji dostarczał projekt).

Struktura folderów aplikacji ASP.NET 2.0

Struktura folderów aplikacji ASP.NET 2.0

Strona ASPX w ASP.NET 2.0 ma cztery tryby projektowe. Pierwszy (View Mark-up po wybraniu z menu podręcznego) to widok kodu strony - kod HTML, znaczniki określające tzw. kontrolki serwerowe (czyli elementy, które serwer ASP.NET przekształci w odpowiednie znaczniki HTML) oraz kod w C# czy VB.NET, zawierający logikę aplikacji. Drugi to widok projektanta (Design View). Pozwala zobaczyć stronę prawie tak, jak będzie ją widział użytkownik. Po wybraniu View Code można też zobaczyć ewentualny kod aplikacji obsługujący daną stronę. I wreszcie jest widok komponentów (Component Designer), w którym zgromadzono niewizualne kontrolki wspomagające aplikację, np. DataSet, DirectorySearcher (do szukania informacji w Active Directory) czy komponenty związane z usługami na danym serwerze. Można też używać MSMQ lub BackgroundWorker do zlecania zadań w tle (z tym jednak trzeba uważać ze względu na krótki czas życia strony-pojemnika). Warto dodać, że w ASP.NET 1.1 tego typu elementy są umieszczane na specjalnym pasku u dołu strony.

W ASP.NET 2.0 zniknęło pojęcie "kontrolek WWW" . Są kontrolki użytkownika (User Control), pozwalające graficznie zaprojektować układ nowego obiektu i przypominające to, co jest w.NET 1.1, ale bez wielu ograniczeń. Natomiast kontrolka to po prostu klasa, która dziedziczy po WebControl, potrafi się narysować jako HTML i wysyłać odpowiedzi do strumienia (Response) kierowanego do przeglądarki klienta. A jeżeli taki obiekt implementuje dodatkowo interfejsy i ma pewne atrybuty, to będzie w odpowiedni sposób pokazany w obszarze projektanta.

W wersji 2.0 zmienił się także model kompilacji. Jest nie tylko code behind, gdzie kod obsługujący daną stronę zostaje kompilowany na zbiorczy plik DLL, ale też code beside, który pozwala, aby kod był nadal oddzielony od strony, ale dodatkowo przed uruchomieniem jest dynamicznie kompilowany na serwerze. Można, oczywiście, mieszać kod HTML i np. C# na jednej stronie ASPX (tzw. code inline), jak w starym ASP (nie .NET). Warto podkreślić, że VS.NET potrafi również w takim kontekście podpowiadać składnię i metody, używając IntelliSense. Oczywiście niezależnie od zastosowanej metody kod przed uruchomieniem zostanie skompilowany. Różnica dotyczy raczej organizacji projektu i wygody programisty.

W ASP.NET drugą składową klas częściowych jest sama strona ASPX, dlatego nie ma, jak w 1.1, kodu deklarującego zmienne odpowiadające elementom formularza WWW. Po prostu umieszczenie kontrolki "serwerowej" jest równoznaczne z generowaniem odpowiedniej zmiennej.

Równocześnie ASP.NET 2.0 ma trochę zmienioną strukturę folderów. W 1.1 był tylko folder bin, który zawierał code behind, czyli skompilowane pliki DLL - kod aplikacji lub zewnętrzne biblioteki. W .NET 2.0 struktura została rozbudowana.

Folderem głównym w wypadku IIS jest folder danej aplikacji WWW.

Warto prześledzić różnice między folderem bin a app_code. W bin można przechowywać skompilowane pakiety (assembly). Mogą to być zarówno zewnętrzne biblioteki używane przez aplikację WWW, jak i code behind do obsługi konkretnych stron ASPX. .NET Framework domyślnie sięga do tego folderu, szukając "nieznanych" bibliotek. Nie trzeba ich w żaden sposób rejestrować. Uwaga! Aplikacje w folderze bin są przeznaczone do jednej aplikacji .NET - innymi słowy, jeżeli mamy kod util.dll, z którego korzystamy w naszych aplikacjach, trzeba tę bibliotekę dołączyć do każdej aplikacji ASP.NET. Można, oczywiście, zarejestrować ją w Global Assembly Cache - wtedy jest dostępna, jak biblioteki systemowe, dla każdej aplikacji uruchamianej na danej maszynie. Warto pamiętać, że jeżeli zmieniamy jakiś plik DLL w folderze bin na nowszą wersję, to .NET 2.0 zatrzymuje AppDomain, w którym działa nasza aplikacja, po czym restartuje cały proces (ale jeżeli kod jest odpowiednio napisany, aplikacja zaś - dobrze skonfigurowana, informacje o sesji użytkownika mogą przetrwać).

Dla porównania to, co umieścimy w folderze app_code, będzie automatycznie kompilowane w czasie działania aplikacji. Plik źródłowy z kodem, który tam umieścimy (napisanym w dowolnym języku .NET), będzie dynamicznie kompilowany i uruchamiany. Oprócz plików z kodem w folderze można umieścić pliki XML (XSD), WSDL (definicje usług WWW) itp. Powodują one wówczas generowanie odpowiedniego pośrednika (proxy) w języku, który został określony w konfiguracji Web.config (dokładniej - w elemencie <compiler>). Można nawet ustawiać domyślnie różne kompilatory do różnych podfolderów. Oto fragment pliku Web.config:

<compilation debug="false">

<codeSubDirectories>

<add directoryName="VBCode" />

<add directoryName="CSCode" />

</codeSubDirectories>

</compilation>

Największą zaletą omawianego modelu programowania jest to, że w momencie zmiany któregoś pliku źródłowego rekompiluje się możliwie najmniejszy fragment aplikacji, a nie całą. Ponadto wgrywanie nowej aplikacji trwa znacznie krócej.

Można też przygotować aplikację do działania w innym trybie - podczas tzw. prekompilacji wygenerować kod MSIL danej witryny i potem go po prostu wgrać. Służy do tego narzędzie aspnet_compiler:

aspnet_compiler -f -p C:\PCWKVS2005\WebTest\ -v / C:\DoWgrania

Można też przekształcić wszystkie pliki - również ASPX, definiujące układ kontrolek na stronach - na postać skompilowaną.

W powyższym przykładzie kod znajdujący się w folderze C:\PCWKVS2005\WebTest, zostanie skompilowany, a odpowiednie pliki będą umieszczone w C:\DoWgrania. Parametr -v / oznacza, że docelowo aplikacja będzie działać w folderze głównym IIS. Analogiczną operację można wykonać także z poziomu środowiska VS. Wystarczy wybrać opcję Build | Publish (która ma mniej opcji, ale pozwala osiągnąć to samo bez opuszczania IDE).

Warto dodać, że w wypadku problemów z prekompilacją pomaga usuwanie wszystkich plików wyjściowych w docelowym folderze. Trzeba też pamiętać, że aplikacja musi dać się skompilować (nie może zawierać błędów składniowych itp.).


Zobacz również