Eastgroup.pl

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

W dzisiejszej lekcji będzie na temat budowania, uruchamiania oraz testowania mobilnych wersji aplikacji webowych stworzonych w technologii ASP.NET.

Tworzenie aplikacji mobilnych mocno nie różni się od tworzenia zwykłych aplikacji webowych. Trzeba tylko pamiętać, że w większości urządzenia mobilne mają większe ograniczenia w stosunku do normalnych komputerów. Dlatego wersje mobilne aplikacji powinny być jak najmniej skomplikowane oraz zawierać jak najmniej elementów, aby urządzenie poradziło sobie z jej wyświetleniem.

Dodanie mobilnej strony do aplikacji

Aplikacja ASP.NET może zawierać jednocześnie strony w wersji normalnej oraz wersje mobilne. Nie ma oddzielnego projektu w Visual Studio dla mobilnych aplikacji ASP.NET. Nie ma również szablonu dla strony mobilnej, który można by wykorzystać dodając taką stronę do projektu. W celu dodania mobilnej strony, programista musi dodać normalną stronę, a następnie zmienić trzy elementy na niej:

• w kodzie behind danej strony zmieniamy klasę, z której dziedziczy klasa strony z System.Web.UI.Page na System.Web.UI.MobileControls.MobilePage
• w kodzie aspx po dyrektywie page dodajemy dyrektywę, która załaduje przestrzeń nazw System.Web.UI.MobileControls, z której będą pochodzi kontrolki na stronie

     1: <%@ Register TagPrefix="mobile" Namespace="System.Web.UI.MobileControls" %>

• zamieniamy wygenerowany przez Visual Studio formularz, który korzysta z wcześniej dodanej przestrzeni nazw:

   1: <mobile:Form id="form1" runat="server">

   2: </mobile:Form>

Mobilne kontrolki

Przestrzeń nazw System.Web.UI.MobileControls udostępnia programiście szereg kontrolek, które może wykorzystać tworząc mobilne wersje aplikacji ASP.NET, które są przystosowane do pracy z urządzeniami mobilnymi. Tymi kontrolkami są między innymi (większość kontrolek jest bardzo podobna do normalnych kontrolek ASP.NET):

• Label – za jej pomocą programista może z poziomu kodu behind wyświetlić tekst na stronie. Gdy ma zostać wyświetlona większa ilość tekstu, lepiej skorzystać z kontrolki TextView
• TextBox – służy do pobierania danych tekstowych od użytkownika
• TextView – służy do wyświetlenia większej ilości tekstu. Umożliwia użycia prostego formatowania HTML (np. a (link), b (pogrubienie), br (znak nowej lini), i (kursywa), p (akapit))
• Command – przycisk, który może kliknąć użytkownik. Wywoływane jest zdarzenie OnClick, gdy użytkownik kliknie w przycisk
• Image – kontrolka służy do wyświetlenie obrazka, w przypadku, gdy format obrazka nie jest obsługiwany, wyświetlany jest tekst z właściwości AlternateText
• List – kontrolka służy do wyświetlenie elementów w formie listy
• SelectionList – jest podobna do kontrolki List, dodatkowo umożliwia wielokrotny elementów z listy
• ObjectList – jest to odpowiednik GridView z normalnego ASP.NET, czyli umożliwia wyświetlenie danych w postaci tabelki
• Calendar – kontrolka kalendarza umożliwiająca wybranie daty przez użytkownika. Kontrolka może wyglądać różnie w zależności od urządzenia (patrz opis niżej)
• Kontrolki walidujące – dostępne są wszystkie kontrolki walidujące dostępne w normalnym ASP.NET

Brak obsługi cookie

Większość urządzeń mobilnych niestety nie obsługuje plików cookie przez co mogą wystąpić problemy między innymi z sesją oraz uwierzytelnianiem, gdzie domyślnie te mechanizmy korzystają z plików cookie (np. do przechowywania ID sesji). Dlatego w przypadku sesji należy ustawić właściwość cookieless na true, dzięki czemu ID sesji będzie przekazywany w adresie url. Aby to zrobić trzeba w web.configu (dla system.web) dodać:

   1: <sessionState cookieless="true" />

Adaptacyjny rendering

Na rynku istnieją różnego rodzaju urządzenia mobilne, które czasami mają bardzo ograniczone możliwości wyświetlania strony. Dlatego kontrolki mobilne ASP.NET umożliwiają renderowanie strony w zależności od przeglądarki, z której jest wysłane żądanie do serwera. I tak na SmartPhonie kontrolka kalendarza może być wyświetlona w sposób identyczny, jak w normalnej wersji strony w przeglądarce na komputerze, co widać na rysunku niżej:

Natomiast w prostym telefonie wybór daty z kalendarza może przebiegać w kilku etapach, co widać na poniższym rysunku:

Gdzie wybór daty może przebiegać w trzech krokach:

• wybór miesiąca np. wrzesień 2006
• wybór tygodniach np. 10 – 16 września
• wybór dnia tygodnia środa 12 września

W każdym żądaniu HTTP jest przekazywany nagłówek User-Agent, w którym znajduje się ciąg znaków identyfikujący przeglądarkę z jakiej korzysta użytkownik. ASP.NET przechowuje w plikach o rozszerzeniu browser konfigurację sposobu wyświetlania strony w zależności od przeglądarki. Globalnie pliki te przechowywane są w katalogu c:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers\. Właśnie na podstawie tych plików ASP.NET decyduje w jaki sposób ma zostać wyświetlona strona, czy to kontrolki (np. Calendar pokazany wyżej).

Dodatkowo programista z poziomu kodu behind może sprawdzić, czy żądanie przyszło z urządzenia mobilnego, czy nie. Na podstawie tej informacji może wykonać odpowiedni kod. Aby to sprawdzić, wystarczy sprawdzić wartość właściwości Request.Browser.IsMobileDevice.

   1: if(Request.Browser.IsMobileDevice)

   2: {

   3:     //kod dla mobilnej wersji   

   4: }else

   5: {

   6:     //kod dla wersji normalnej

   7: }

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

ASP.NET udostępnia programiście mechanizm profili, który może wykorzystać do przechowywania informacji specyficznych dla poszczególnych użytkowników. Informacje przechowywane mogę być dowolne np. szablon strony, adres zamieszkania lub dowolne dane potrzebne do działania aplikacji. Dane te są przechowywane między kolejnymi wizytami użytkownika na stronie. ASP.NET automatycznie ładuje dane z źródła na podstawie tożsamości użytkownika. W tym artykule zostanie opisana praca z mechanizmem profili ASP.NET.

Aby wykorzystać powyższy mechanizm należy zrobić kilka kroków:

• Konfiguracja providera, który zostanie wykorzystany przez mechanizm
• Zdefiniować przechowywane dane
• Ustawić i zapisać dane w profilu
• Rozpoznać powracającego użytkownika i wykorzystać dane w profilu

Konfiguracja providera

Domyślnie ASP.NET posiada skonfigurowanego SqlProfileProvidera, który przechowuje dane w lokalnej bazie danych MS Sql Server. Baza ta znajduje się w pliku (ASPNETDB.MDF) i jest w katalogu App_Data. Natomiast domyślna konfiguracja znajduje się w pliku machine.config i wygląda następująco:

   1: <connectionStrings>

   2:     <add name="LocalSqlServer" 

   3:         connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" 

   4:         providerName="System.Data.SqlClient"/>

   5: </connectionStrings>

   1: <profile>

   2:     <providers>

   3:         <add name="AspNetSqlProfileProvider"

   4:             connectionStringName="LocalSqlServer"

   5:             applicationName="/"

   6:             type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

   7:     </providers>

   8: </profile>

W przypadku, gdy programista chce skorzystać z innej bazy musi zmienić connectionStringa, który będzie zawierał informacje o sposobie połączenia z bazą oraz musi wygenerować odpowiednią strukturę danych w bazie. Aby wygenerować odpowiednią strukturę wystarczy skorzystać z narzędzia aspnet_regsql.exe, które znajduje się w katalogu %windows%\Microsoft.NET\Framework\%version%, a jego składania powinna wyglądać mniej więcej tak:

   1: aspnet_regsql.exe -E -S localhost -Ap

Gdzie parametr S oznacza serwer z którym ma się połączyć narzędzie (tutaj localhost), parametr E oznacza, że łącząc się z serwerem ma zostać wykorzystana tożsamość konta Windows oraz parametr –Ap oznacza wygenerowanie tabel potrzebnych do działania mechanizmu profili.

Sama narzędzie aspnet_regsql.exe jest dużo bardziej rozbudowane, ponieważ umożliwia generowanie nie tylko tabel dla profili ale również dla membershipprovidera, roleprovidera oraz web parts.

Definicja danych profilu

Mając już skonfigurowanego providera dla mechanizmu profili, następnym krokiem jest zdefiniowane danych jakie profil będzie mógł przechowywać. Dane definiujemy w pliku konfiguracyjnym web.config. Poniżej znajduje się przykład, który umożliwia przechowywanie imienia, nazwiska oraz datę ostatniej wizyty użytkownika. Jak widać dla danych o typie string nie trzeba podawać typu, ponieważ jest to domyślny typ danych.

   1: <system.web>

   2:     <profile>

   3:         <properties>

   4:             <add name="FirstName"/>

   5:             <add name="LastName"/>

   6:             <add name="LastVisit" type="System.DateTime"/>

   7:         </properties>

   8:     </profile>

   9: </system.web>

Dodatkowo możemy ustawić, że część pól profilu będzie mogła być ustawiana dla użytkowników anonimowych. W tym celu należy przy definicji danego pola dodać atrybut allowAnonymous="true" oraz dodać element <anonymousIdentification enabled="true"/> do system.web. W przypadku nieuwierzytelnionych użytkowników ASP.NET generuje unikalną wartość, która później zapisuje do pliku cookie, na podstawie, której później może zidentyfikować powracającego użytkownika.

Ustawianie i zapisywanie danych w profilu

Ustawianie i zapisywanie danych jest bardzo proste. Programista ma dostęp do właściwości Profile, które jest generowana na podstawie pliku web.config i zawiera wszystkie zdefiniowane tam właściwości. Na koniec po ustawieniu wszystkich właściwości trzeba wywołać metodę Save.

   1: Profile.FirstName = "Daniel";

   2: Profile.LastName = "Plawgo";

   3: Profile.Save();

Odczytywanie danych z profilu

Odczytanie danych jest jeszcze łatwiejsze niż ich zapis. ASP.NET automatycznie ładuje dane użytkownika na podstawie jego tożsamości i już w kodzie aplikacji możemy korzystać z właściwości Profile, która ma ustawione wszystkie właściwości na dane wcześniej zapisane.

   1: FirstNameTextBox.Text = Profile.FirstName;

   2: LastNameTextBox.Text = Profile.LastName;

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

Nie wszystkie problemy z aplikacją ASP.NET mogą zostać znalezione za pomocą Visual Studio. Dlatego ASP.NET udostępnia możliwość śledzenia oraz sprawdzenia sposobu wykonywania się kodu aplikacji w środowisku testów oraz produkcyjnym. Dzięki czemu programista może zbadać działanie aplikacji podczas problemów, które jest trudno odtworzyć na maszynie developerskiej.

Tracing

Tracing (śledzenie) jest procesem zwracania programiście informacji o działającej aplikacji. W ASP.NET dane te zostają zapisane do pliku, który później można przejrzeć za pomocą przeglądarki. Dane te zawierają ważne dane o aplikacji. Takie jak: kto odwiedza witrynę, rezultaty jakie są otrzymywane, jak wyglądają dane protokołu HTTP i wiele, wiele innych.

Uruchomić Tracing można na dwa sposoby (które tak na prawdę robią to samo): za pomocą narzędzia administracyjnego witryny sieci Web oraz dodając odpowiedni wpis w pliku konfiguracyjnym Web.config.

Aby włączyć Tracing za pomocą narzędzia administracyjnego witryny sieci Web, uruchamiany to narzędzie za pomocą ikony w solution explorer (taki “globus z motkiem”). Następnie przechodzimy do zakładki Aplikacja i tam mamy link do strony konfiguracji debugowania oraz śledzenia. Na stronie tej zaznaczamy “Przechwytuj informacje o śledzeniu”. Dodatkowo możemy sobie ustawić różne ustawieni śledzenia. Poniżej screen strony:

Narzędzia administracyjne witryny sieci web tak naprawdę dodaje odpowiedni wpis w pliku konfiguracyjnym Web.config. To samo można było zrobić dodając poniższy fragment do tego pliku:

   1: <trace enabled="true"

   2:        requestLimit="100"

   3:        pageOutput="false"

   4:        traceMode="SortByTime"

   5:        localOnly="false"

   6:        mostRecent="true" />

Gdzie kolejne opcje oznaczają:

• enabled – ustawienie na wartość true powoduje uruchomienie w aplikacji Tracing
• requestLimit – ilość rekordów przechowywanych w cachu lub pliku logów
• pageOutput – za pomocą tej opcji można ustawić, czy informację o Tracing są wyświetlane na poszczególnych stronach (dane te wyświetlają są na samym końcu strony)
• traceMode – sposób sortowania wpisów
• localOnly – możliwość ustawienia, że informację będę wyświetlana tylko dla lokalnych połączeń do witryny
• mostRecent – ustawienie przechowywania informacji o ostatnich żądaniach do strony

Informacje zbierane przez Tracing można wyświetlić na dwa sposoby: otworzyć stronę trace.axd w głównym katalogu aplikacji lub ustawić wyświetlanie informacji na poszczególnych stronach (na takiej stronie trzeba ustawić właściwość Trace na true w dyrektywie Page na samej górze strony).

Programista może sobie sam programowo dodać wpisy do mechanizmu Tracing. W przestrzeni nazw System.Diagnostics znajduje się klasa Trace, która posiada metodę write dodającą wpis do mechanizmu Tracing. Przykładowa wywołanie metody to:

   1: Trace.Write("Kategoria", "Test");

Gdzie wpis znajdzie się w kategorii “Kategoria”, a jego treść to “Test”.

Monitorowanie aplikacji

Mechanizm Tracing bardzo przydaje się do znajdowania błędów i problemów z poszczególnymi stronami. Z drugiej strony bardzo często programista potrzebuje otrzymać informacji o działaniu całej aplikacji. ASP.NET zawiera szereg klas umożliwiających monitorowania działania strony. Monitorowane są zdarzenia wywoływane przez aplikację.

Aby uruchomić monitorowanie wystarczy dodać do pliku konfiguracyjnego web.config odpowiedni wpis. Poniżej przykład:

   1: <healthMonitoring enabled="true" heartbeatInterval="1">

   2:   <rules>

   3:     <add name="Heart Beat"

   4:          eventName="Hearbeats"

   5:          profile="EventLogProvider"

   6:          provider="Default"/>

   7:   </rules>

   8: </healthMonitoring>

Już 5 maja 2010 roku (środa) o godzinie 17:00 na Wydziale Matematyki i Informatyki UWM w Olsztynie startuje Visual Studio 2010 Community Launch.

12 kwietnia 2010 roku miała swoją premierę nowa wersja środowiska programistycznego firmy Microsoft - Visual Studio 2010. Kolejna odsłona tego świetnego produktu umożliwia programiście szybsze i wydajniejsze tworzenie aplikacji biznesowych.

Polskie społeczności skupione wokół produktów firmy Microsoft organizują w swoich miastach spotkania, mające na celu przybliżenie najnowszej wersji środowiska Visual Studio tak swoim członkom, jak i innym chętnym poszerzenia swojej wiedzy.

Jednym z miast, które bierze udział w cyklu, jest Olsztyn. W środowy wieczór będzie można obejrzeć dwie prezentacje na temat Visual Studio 2010:

· Nowości w Visual Studio 2010 - Sesja ma za zadanie wprowadzić uczestników w tematykę związaną z Visual Studio 2010, przede wszystkim zaś w zmiany, które w nim zaszły oraz wprowadzone nowości.

· IntelliTrace - nowe podejście do śledzenia aplikacji - Debbuger historyczny to narzędzie, który zupełnie zmieni sposób pracy programisty. To swoista "maszyna czasu dla deweloperów i testerów". Rejestruje historię działania aplikacji i pozwala odtworzyć to, jak doszło do wystąpienia danego błędu. Sesja ma przybliżyć to narzędzie użytkownikom.

W przerwie między prezentacjami będzie można zintegrować się ze społecznością oraz zebrać siły przed drugą prezentacją, posilając się dużą ilością pizzy J

Wśród uczestników spotkania rozlosowane zostaną cenne nagrody o łącznej wartości ok. 10 000zł! Będą to między innymi licencje na produkty, takie jak Telerik Premium Collection o wartości 1299$, ReSharper, Nevron Chart for .NET Lite, Gauge for SSRS, CodeRush with Refactor! Pro czy Typemock Isolator. Do rozdania mamy także książki ufundowane przez wydawnictwo O’Reilly – CLR via C# oraz C# 4.0 in a Nutshell.

Udział w wydarzeniu jest bezpłatny, wymagana jest rejestracja na stronie.

Przyjdź na Visual Studio 2010 Community Launch, poznaj najnowsze środowisko programistyczne Micosoftu, poszerz swoją wiedzę i dobrze baw się z nami!!!

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

Tworząc aplikacje internetowe istnieje kilka scenariuszy, które różnią się od typowego scenariusza żądanie – obsługa żądania. Przykładem takich scenariuszy może być łapanie wyjątków na poziomie całej strony lub całej aplikacji, wykonywanie zadań asynchronicznie, tworzenie specyficznych handlerów dla protokołu HTTP.

Dzisiejszy artykuł będzie właśnie opisywał tego typu scenariusze.

Wyjątki na poziomie aplikacji oraz strony

Tworząc aplikacji programiści wykorzystują wyjątki oraz bloki try-catch do obsługi sytuacji wyjątkowych. Aby obsługa ta była efektywna w bloki try-catch powinno się obejmować jak najmniejsze fragmenty kodu. Takich przykładem może być fragment kodu, w którym następuje połączenie do bazy danych i wyciągnięcie z niej informacji. Jednakże programista na ogól nie jest w stanie lub nie opłaca mu się to, aby tworzyć kod dla wszystkich możliwych do wyrzucenia wyjątkach. Dlatego ASP.NET umożliwia wyłapywanie wyjątków na poziomie całej strony lub całej aplikacji.

W celu wyłapania wszystkich wyjątków występujących na danej stronie, które nie zostały obsłużone wystarczy dodać do kodu strony metodę Page_Error, która może wyglądać następująco:

   1: protected void Page_Error(object sender, EventArgs e)

   2: {

   3:     var error = Server.GetLastError(); //wyciągnięcie ostatniego błędu

   4:     string message = error.Message;

   5:     Server.ClearError(); //wyczyszczenie listy błędów

   6:     Response.Write("Nieoczekiwany błąd: " + message); //wyświetlenie komunikatu

   7: }

ASP.NET umożliwia również wyłapywanie nieobsłużonych wyjątków na poziomie samej aplikacji. Aby dodać obsługę wystarczy dodać do klasy Global znajdującej się w pliku Global.asax metodę Application_Error, która może wyglądać następująco:

   1: protected void Application_Error(object sender, EventArgs e)

   2: {

   3:     //kod wykonany, gdy nastąpił nieobslużony wyjątek

   4:     Server.Transfer("HandleError.aspx");

   5: }

Podobnie jak w przypadku wyłapywaniu wyjątków na poziomie pojedynczej strony mamy dostęp do właściwości Server.

Dostęp do pliku Web.config

ASP.NET udostępnia również możliwość z programowego dostępu do pliku Web.config, w którym znajduje się konfiguracja aplikacji. W tym celu trzeba skorzystać z klasy WebConfigurationManager znajdującej się w przestrzeni nazw System.Web.Configuration. Aby odczytać jakąś sekcje z pliku konfiguracyjnego, wywołujemy metodę GetSection klasy WebConfigurationManager i przekazujemy do niej sekcje jaką chcemy odczytać. Co ważne, metoda ta zwraca typ object, dlatego musimy jeszcze zrzutować na odpowiedni typ związany z daną sekcją. Poniżej przykład kod, za pomocą którego można odczytać tryb uwierzytelniania.

   1: AuthenticationSection section =

   2:     (AuthenticationSection) WebConfigurationManager.GetSection("system.web/authentication");

   3:  

   4: string mode = section.Mode.ToString();

Klasa WebConfigurationManager umożliwia również odczytywanie ustawień aplikacji zdefiniowanych przez programistę w pliku konfiguracyjnym. Wystarczy skorzystać z właściwości AppSettings, jak to widać niżej na przykładzie:

   1: string mySetting = WebConfigurationManager.AppSettings["MySetting"];

Również klasa ta umożliwia łatwe odczytanie connection stringa z pliku Web.config. Wystarczy skorzystać z właściwości ConnectionStrings:

   1: string connectionString = WebConfigurationManager.ConnectionStrings["MyConnection"].ConnectionString;

Klasa WebConfigurationManager bardzo dobrze nadaje się do odczytywania ustawień aplikacji, już gorzej jest z zapisywaniem nowych ustawień. W celu zmiany ustawień i zapisania powinno skorzystać się z klasy Configuration z przestrzeni nazw System.Configuration.

W celu zmiany konfiguracji wywołujemy metodę OpenWebConfiguration klasy WebConfigurationManager, która właśnie zwraca obiekt klasy Configuration. Następnie za pomocą metody GetSection wyciągamy odpowiednią sekcję z pliku. Zmieniamy właściwości i na koniec wywołujemy metodę Save obiektu klasy Configuration. Najlepiej to zobaczyć na przykładzie:

   1: Configuration configuration = WebConfigurationManager.OpenWebConfiguration(null);

   2: AuthenticationSection authenticationSection = (AuthenticationSection)configuration.GetSection("system.web/authentication");

   3: authenticationSection.Mode = AuthenticationMode.Forms;

   4: configuration.Save();

Natomiast, aby zapisać plik konfiguracyjnym w innym miejscu wystarczy wywołać metodę SaveAs i przekazać do niej nową lokalizację pliku.

HTTP Handler

HTTP Handler jest kodem, który jest wykonywany w przypadku żądania HTTP do serwera dla określonego zasobu. Przykładowym HTTP handlerem jest ASP.NET page handler, który jest uruchamiany, gdy do serwera przyjdzie żądanie od pliku *.aspx.

Programista może dodawać do aplikacji webowej swoje własne handlery, w celu wykonywania kod specyficznego dla danego typu zasobu. Takim przykładowym handlerem może być handler, który generuje obrazki z ciągiem znaków, który może posłużyć za mechanizm zabezpieczający formularz przed wysyłaniem zbędnych wiadomości.

Aby stworzyć swój własny handler wystarczy do projektu dodać klasę, która implementuje interfejs IHttpHandler. Implementując ten interfejs musimy zaimplementować jedną właściwość (IsReusable) oraz jedną metodę (ProcessRequest).

Właściwość IsReusable informuje ASP.NET, czy instancje handlera mogą być wykorzystywane kilkakrotnie, czy dla każdego nowego żądania powinien być tworzony od nowa handler.

Natomiast metoda ProcessRequest wykonuje właściwy kod dla danego żądania do zasobu. Przykładowa implementacja może wyglądać następująco:

   1: public class ImageHttpHandler : IHttpHandler

   2: {

   3:     #region IHttpHandler Members

   4:  

   5:     public bool IsReusable

   6:     {

   7:         get { return false; }

   8:     }

   9:  

  10:     public void ProcessRequest(HttpContext context)

  11:     {

  12:         context.Response.ContentType = "image/jpeg";

  13:         Image image = CreateImage();

  14:         context.Response.Write(image);

  15:     }

  16:  

  17:     private Image CreateImage()...

  18:  

  19:     #endregion

  20: }

Na koniec wystarczy do pliku Web.config do sekcji system.web dodać informacje o handlerze oraz zasobie, do jakiego ma być wywoływany handler:

   1: <httpHandlers>

   2:   <add verb="*" path="*.jpg" type="ImageHandler"/>

   3:   <add verb="*" path="*.gif" type="ImageHandler"/>

   4: </httpHandlers>

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

W dzisiejszym artykule będzie na temat tworzenia i korzystania z web serwisów wykorzystujących technologię Windows Communication Foundation. Artykuł będzie wprowadzeniem do tej technologii. Jeśli ktoś będzie bardziej zainteresowany nią, to po więcej informacji odsyłam do równoległej serii artykułów przygotowujących do egzaminu właśnie z WCFa.

Windows Communication Foundation to technologia, która po raz pierwszy pojawiła się wraz z wersją 3.0 .NET Frameworka. WCF jest to zunifikowany model programistyczny do wszelkiego rodzaju komunikacji rozproszonej. Dzięki WCFowi identycznie pracujemy z różnymi sposobami przesyłania danych przez sieć, niezależnie, czy fizycznie wykorzystujemy połączenia TCP, czy na przykład protokół HTTP i SOAPa.

W artykule tak jak już pisałem skupie się na podstawach, a dokładniej pokaże jak tworzyć serwis WCFa oraz jak go wykorzystywać w aplikacjach ASP.NET.

Aby stworzyć i korzystać z serwisu napisanego w WCFie, trzeba zrobić kilka kroków:

1. Zdefiniować kontrakt serwisu
2. Zaimplementować ten kontrakt
3. Skonfigurować punkty dostępowe serwisu
4. Hostować serwis
5. Dodać referencje do serwisu w aplikacji klienckiej i go wykorzystywać

W Visual Studio jest specjalny typ projektu, który umożliwia stworzenie serwisu Windows Communication Foundation – WCF Service Application. Po stworzeniu tego typu projektu mamy domyślnie dodane między innymi dwa pliki: IService1.cs oraz Service1.svc, w których odpowiednio znajduje się kontrakt serwisu oraz jego implementacja.

Przeglądając zawartość pliku IService1.cs można zauważyć, że znajduje się tam jeden interfejs oraz jedna klasa. Od razu rzuca się w oczy, że sam interfejs i klasa są oznaczone specjalnymi atrybutami oraz metody i właściwości też są oznaczone. W WCFie, aby zdefiniować kontrakt wykorzystuje się atrybuty. Mamy 4 podstawowe atrybuty:

• ServiceContract – za jego pomocą oznacza się interfejs lub klasę, która ma definiować kontrakt serwisu WCFowego. Atrybut ten może przyjmować parametry, za pomocą których można zdefiniować właściwości serwisu.
• OperationContract – atrybut ten służy do oznaczania metod w interfejsie lub klasie kontraktu, która będzie w ramach jego wchodziła i którą klient będzie mógł wywoływać
• DataContract – atrybutem tym oznacza się typu (klasy, struktury, wyliczenia), które będą przesyłane przez sieć.
• DataMember – atrybutem tym oznacza się właściwości oraz pola klasy czy struktury, które mają być serializowane podczas przesyłania obiektów przez sieć.

Visual Studio bardzo pomaga tworzenie WCFowego serwisu. Wystarczy do projektu dodać WCF Service, a Visual Studio wygeneruje sam automatycznie szkielet pliku z interfejsem kontraktu, klasę implementująca dany serwis oraz odpowiednie wpisy w pliku Web.config.

Przykładowy kontrakt serwisu oznaczony powyższymi atrybutami może wyglądać tak:

   1: [ServiceContract]

   2: public interface ICustomerServices

   3: {

   4:     [OperationContract]

   5:     Customer GetCustomer(int id);

   6:  

   7:     [OperationContract]

   8:     void DeleteCustomer(int id);

   9: }

  10:  

  11: [DataContract]

  12: public class Customer

  13: {

  14:     [DataMember]

  15:     public int Id { get; set;}

  16:  

  17:     [DataMember]

  18:     public string FirstName { get; set;}

  19:  

  20:     [DataMember]

  21:     public string LastName { get; set;}

  22: }

Mając już zdefiniowany kontrakt wygenerowanym przez Visual Studio pliku *.svc implementujemy logikę serwisu.

Visual Studio automatycznie dodaj do Web.configa odpowiednie wpisy konfigurujące serwis (podstawową typową konfigurację). Wygląda ona następująco:

   1: <system.serviceModel>

   2:   <services>

   3:     <service behaviorConfiguration="WcfService1.CustomerServicesBehavior"

   4:   name="WcfService1.CustomerServices">

   5:       <endpoint address="" binding="wsHttpBinding" contract="WcfService1.ICustomerServices">

   6:         <identity>

   7:           <dns value="localhost" />

   8:         </identity>

   9:       </endpoint>

  10:       <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

  11:     </service>

  12:   </services>

  13:   <behaviors>

  14:     <serviceBehaviors>

  15:       <behavior name="WcfService1.CustomerServicesBehavior">

  16:         <serviceMetadata httpGetEnabled="true" />

  17:         <serviceDebug includeExceptionDetailInFaults="false" />

  18:       </behavior>

  19:     </serviceBehaviors>

  20:   </behaviors>

  21: </system.serviceModel>

Nie będę szczegółowo opisywał całej konfiguracji. Z ważniejszych rzeczy w niej są konfiguracji endpointów. Za ich pomocą definiuje się punkty dostępowe do serwisu. Jego adres, wykorzystywany binding itp.

Mając już stworzony serwis pozostaje tylko go wykorzystać. W tym celu trzeba wrzucić projekt na serwer i do innego projektu dodać referencje. Klikamy prawym na nazwę projektu i z menu wybieram Add Service Reference. W okienku, które się pojawi wpisuje adres serwisu, możemy sprawdzić sobie jakie kontrakty zawiera dany serwis oraz na koniec wygenerować klasy odpowiedzialne za komunikacje z serwisem. Okienko wygląda następująco:

Została wygenerowana klasa w tym przypadku CustomerServicesClient, za pomocą której możemy wywoływać metody serwisu, jak zwykłe metody:

   1: CustomerServicesClient client = new CustomerServicesClient();

   2: client.GetCustomer(20);

Co fajnie w WCFie jest to, że możemy korzystać z różnych sposób przesyłania informacji. Sam kod wykorzystujący serwis się nie zmienia, tylko wszystko jest ustawione w pliku konfiguracyjnym.

To byłoby by na tyle z podstaw Windows Communication Foundation. Jak ktoś jest bardziej zainteresowany tą technologią to polecam artykuły z serii przygotowującej do egzaminu z tej technologii.

Artykuł pochodzi w serii przygotowań do egzaminu 70-562 ASP.NET.

W ostatnich trzech artykułach z serii przygotowań do egzaminu 70-562 opisywane były sposoby pracy nad danymi przy wykorzystaniu ADO.NET. Klasy przedstawione w tych wpisach pokazywały jak programista może zrobić sobie za ich pomocą abstrakcyjną warstwę dostępu do danych. Jednak często, w szczególności przy prostych aplikacja www wykorzystywanie ADO.NET jest czasochłonne i nie wygodne. Na szczęście ASP.NET udostępnia zbiór kontrolek dostępu do danych, za pomocą których w sposób deklaratywnych można uzyskać dostęp do danych. Kontrolki te stanowią opakowanie kod ADO.NET, dzięki czemu pracuje się z nimi w miarę prosto i wygodnie. W artykule zostaną opisane następujące kontrolki: ObjectDataSource, SqlDataSource, LinqDataSource, AccessDataSource, XmlDataSource, SiteMapDataSource.

Zrozumieć kontrolki źródła danych

Kontrolki źródła danych ASP.NET zarządzają zadaniami takimi jak wyciąganie, aktualizacja, dodawanie, usuwanie danych na stronie. Kontrolki źródła danych w docelowym kodzie html stronie nie mają swojego odwzorowania. Odpowiadają tylko za zarządzanie danymi. W celu wyświetlania danych programista musi skorzystać z innych kontrolek stworzonych w tym celu (np. DetailsView, GridView, które będę opisane w następnym artykule).

Wszystkie kontrolki źródła danych znajdują się w przestrzeni nazw System.Web.UI.WebControls, a poniżej znajduje się rysunek z strukturą klas.

Praca z wszystkimi kontrolkami źródła danych jest bardzo podobna. Pierw, aby skorzystać z kontrolki musimy ją przeciągnąć z toolboxa na formatkę strony, następnie skonfigurować, a na koniec podpiąć do kontrolki, która zaprezentuje użytkownikowi dane. Skonfigurować kontrolkę można na dwa sposobu: ustawiając odpowiednie atrybuty kontrolki w znacznika ASP.NET lub skorzystać z kreatora znajdującego się w Visual Studio (poniżej zrzut z jednego z widoków kreatora).

ObjectDataSource

Pierwszą kontrolką, którą opisze to ObjectDataSource. Kontrolkę tą można użyć w przypadku, gdy już mamy napisaną warstwę dostępu do danych (w ogólności klasę z metodą, która zwraca jakieś dane) i z niej operować na danych. Przykładowo mamy klasę Customer, a w niej metodę GetAllCustomer, która zwraca wszystkich klientów. Przykładowy kod poniżej:

   1: public class Customer

   2: {

   3:     private static string connectionString;

   4:  

   5:     public static DataTable GetAllCustomers()

   6:     {

   7:         SqlDataAdapter adapter = new SqlDataAdapter("SELECT * FROM Customer;", connectionString);

   8:  

   9:         DataSet dataSet = new DataSet("Customers");

  10:  

  11:         adapter.Fill(dataSet);

  12:  

  13:         return dataSet.Tables[0];

  14:     }

  15: }

Aby skorzystać z kontrolki ObjectDataSource wystarczy ją dodać do formatki strony oraz ustawić dwie właściwości: TypName (określa typ jaki ma być wykorzystany przy wyciąganiu danych – przykładowo klasa Customer) oraz SelectMethod (określa metodę z typu, która ma być wywołana – GetAllCustomers). Poniżej kod ASP kontroli z ustawionymi oboma atrybutami:

   1: <asp:ObjectDataSource ID="ObjectDataSource1" runat="server" TypeName="Customer" SelectMethod="GetAllCustomers">

   2: </asp:ObjectDataSource>

Kontrolki źródła danych umożliwiają nie tylko wyciąganie danych ale również dodawanie danych do źródła, ich aktualizację oraz usuwanie. W przypadku kontrolki ObjectDataSource, gdy mamy klasę robiące powyższe czynności wystarczy ustawić odpowiednie nazwy metoda dla odpowiednich atrybutów (DeleteMethod – metoda usuwające dane, InsertMethod – metoda dodająca dane oraz UpdateMethod – metoda aktualizująca dane).

Kontrolkę ObjectDataSource można tak skonfigurować, aby przekazywała parametry do metod (np. id klienta, który ma zostać usunięty). Parametry mogą pochodzić z różnych źródeł. Poniższa tabelka przedstawia dostępne opcje:

I tak jak chcemy przekazać do metody usuwającej klienta jego id, to do kontrolki dodajemy odpowiedni znacznik jak poniżej:

   1: <DeleteParameters>

   2:      <asp:QueryStringParameter Name="id" QueryStringField="CustomerId" Type="Int32" />

   3: </DeleteParameters>

I jak widać na listingu powyższym, parametr będzie pochodzi z adresu URL (znacznik QueryStringParameter), nazwę parametru z adresu URL ustawiamy za pomocą atrybutu QueryStringFiels (w przykładzie CustomerId), typ parametru za pomocą atrybutu Type (przykład Int32) oraz za pomocą atrybutu Name ustawiamy nazwę parametru w metodzie (w przykładzie id). Podobnie robimy dla pozostałych typów metod.

Kontrola ObjectDataSource umożliwia jeszcze kilka ciekawych rzeczy: filtrowanie danych, sortowanie, stronicowanie oraz keszowanie danych. Wystarczy ustawić odpowiednie właściwości kontrolki, aby wykorzystywać powyższe funkcje.

W przypadku filtrowania ustawiamy do właściwości kontroli FilterExpression wyrażenie filtrujące. Parametry do filtrowania możemy przekazać podobnie jak inne parametry. Przykład:

   1: <asp:ObjectDataSource ID="ObjectDataSource1" runat="server" TypeName="Customer" SelectMethod="GetAllCustomers"

   2:     FilterExpression="city='{0}'">

   3:     <FilterParameters>

   4:         <asp:QueryStringParameter Name="city" QueryStringField="city" Type="string" />

   5:     </FilterParameters>

   6: </asp:ObjectDataSource>

W przypadku sortowania oraz stronicowania, to aby skorzystać z tych funkcjonalności metoda, która jest wykorzystywana do wyciągania danych (właściwość SelectMethod kontrolki ObjectDataSource) musi przyjmować trzy dodatkowe parametry: kolumnę do sortowania, numer indeksu, od które maja zostać wciągane wiersze danych oraz ilość wierzy do wyciągnięcia. Mając już poprawną metodę wystarczy ustawić odpowiednie właściwości kontrolki: EnablePaging na true, SortParameterName na nazwę parametru z metody, która określa kolumnę do sortowania, StartRowIndexParameterName na nazwę parametru z metody, który określa numer wiersza, od którego mają być pobierane dane oraz MaximumRowsParameterName na nazwę parametru metody, który określa ilość wierszy do wyciągnięcia.

Natomiast, aby wykorzystać keszowanie przy wyciąganiu danych za pomocą kontrolki wystarczy ustawić dwa atrybuty: EnableCaching na true oraz CacheDuration na ilość sekund przez jaki czas dane mają nie być wyciągane z źródła.

Z pozostałymi kontrolkami pracy wygląda bardzo podobnie i chęć elementów są identyczne, dlatego w opisie kolejnych kontrolkach będą zaznaczał te aspekty, które się różnią.

SqlDataSource

Kontrolka SqlDataSource służy do dostępu do danych znajdujących się w relacyjnych bazach danych takich jak SQL Server czy Oracl. Dodatkowo kontrolka umożliwia połączenia się z Open Database Connectivity (ODBC) oraz Object Linking and Embedding (OLE).

W przypadku SqlDataSource nie mamy właściwości typu SelectMethod jak w ObjectDataSource ale mamy właściwości typu [nazwaoperacji]Command (np. SelectCommand). Dodatkowo musimy ustawić jeszcze kilka właściwości: ConnectionString, w której jest zapisana informacja o sposobie połączenia z bazą danych, DataSourceMode, która ma dwie wartości DataReader oraz DataSet, informuje kontrolkę jakiego obiektu ADO.NET użyć do połączenia z bazą danych. Na koniec trzeba jeszcze ustawić typ komendy (np. SelectCommandType), tutaj również mamy dwie możliwości: Text oraz StoredProcedure.

Przykład zastosowania kontrolki SqlDataSource:

   1: <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectingStrings:ConnectionString %>"

   2:     SelectCommandType="Text" SelectCommand="Select * from Customer where city=@city"

   3:     DataSourceMode="DataReader">

   4:     <SelectParameters>

   5:         <asp:SessionParameter SessionField="city" Name="city" Type="String" />

   6:     </SelectParameters>

   7: </asp:SqlDataSource>

AccessDataSource

AccessDataSource służy do wyciągania danych z pliku Access, który jest elementem pakietu Microsoft Office. Jak widać na wcześniej załączonym rysunku AccessDataSource bezpośrednio dziedziczy z SqlDataSource, więc pracuje się z nią praktycznie identycznie. Różnica polega na tym, że zamiast właściwości ConnectionString ustawia się właściwość DataFile.

XmlDataSource

Kontrolka XmlDataSource służy do operacji na danych znajdujących się w pliku xml. Niestety kontrolka ta służy tylko do wyciągania danych z pliku. Nie wspiera operacji typu dodawanie, usuwanie, aktualizacja danych w pliku. Jeśli chcemy wykonywać takie operacje musimy napisać swój własny kod (metody pracy z plikami xml były opisywane w poprzedniej lekcji).

W celu pracy z kontrolką musimy ustawiać właściwość DataFile, na ścieżkę do pliku xml z danymi. Dodatkowo mają plik Extensible Stylesheet Language (XSL) możemy go podpiąć do kontrolki i za jego pomocą zmienić kształt oraz zawartość danych. Ścieżkę do pliku xsl ustawiamy za pomocą właściwości TransformFile.

LinqDataSource

ASP.NET umożliwia operacje na danymi za pomocą Linq. Deklaracja kontrolki LinqDataSource jest trochę inna od pozostałych kontrolek, co najlepiej zobaczyć na przykładzie:

   1: <asp:LinqDataSource ContextTypeName="ExampleDataContext" TableName="Products" Where="Price > 50"

   2:     ID="LinqDataSource1" EnableUpdate="true" EnableInsert="true" EnableDelete="true"

   3:     runat="server">

   4: </asp:LinqDataSource>

Najważniejszą właściwością w przypadku kontrolki LinqDataSource jest ContextTypeName, do której przekazujemy nazwę klasy, która została wygenerowana przez Linq i za pomocą, której wykonujemy wszystkie operacja na danych.

SiteMapDataSource

W aplikacjach ASP.NET istnieje specjalny plik Web.sitemap, w którym programista może zapisać strukturę aplikacji, na podstawie której można zbudować menu aplikacji. Plik Web.sitemap może wyglądać mniej więcej tak:

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >

   3:     <siteMapNode url="default.aspx" title="Strona główna"  description="Strona główna">

   4:         <siteMapNode url="customers.aspx" title="Klienci"  description="Lista klientów" />

   5:         <siteMapNode url="products.aspx" title="Produkty"  description="Lista produktów" />

   6:     </siteMapNode>

   7: </siteMap>