Rozdział 15.
Zastosowanie obiektów biznesowych

W tym rozdziale zajmiemy się nowym obszarem zastosowań ASP.NET. W dwóch poprzednich częściach książki przedstawione zostały podstawowe informacje na temat tej technologii oraz mechanizmy dostępu do danych. Teraz zajmiemy się zagadnieniami zaawansowanymi, które pozwolą Ci na tworzenie pełnych aplikacji ASP.NET.

W tym rozdziale poznasz obiekty biznesowe — czyli komponenty których będziesz mógł używać w swoich aplikacjach ASP.NET. Różnica pomiędzy obiektami biznesowymi a komponentami których używaliśmy do tej pory (takimi jak obiekty ADO.NET oraz obiekty do obsługi danych XML) polega na tym, iż obiekty biznesowe będziemy w całości tworzyli własnoręcznie. W tym rozdziale dowiesz się do czego one służą oraz jak należy je tworzyć i używać.

W tym rozdziale zostaną omówione następujące zagadnienia:

·         Czym są komponenty i obiekty biznesowe.

·         W jaki sposób ASP.NET korzysta z komponentów.

·         Jak można używać komponentów.

·         Jak tworzyć i używać obiektów biznesowych.

·         W jaki sposób można korzystać z komponentów, które nie zostały utworzone w środowisku .NET.

Prezentacja komponentów

Komponenty to obiekty, które mogą być wielokrotnie wykorzystywane w wielu różnych aplikacjach. Zazwyczaj odwzorowują one obiekty spotykane w realnym świecie. Wykorzystajmy jeszcze raz przykład z fabryką zegarów, przedstawiony w rozdziale 3, pt.: „Stosowanie Visual Basic.NET”. Aby zbudować zegar należy przygotować odpowiednie komponenty, takie jak sprężyny, koła zębate, szkło, drewno oraz wahadło i złożyć je w jedną całość. W bardzo podobny sposób są tworzone aplikacje ASP.NET oraz zwyczajne aplikacje. Składają się one z wielu części, które po złożeniu tworzą jedną spójną całość.

Wyobraź sobie, że tworzone przez Ciebie zegary składają się tylko z jednego komponentu — każdy zegar jest jednym kawałkiem drzewa. Takie zegary nie będą działać najlepiej — wskazówki nie będą się kręcić, a wahadło — poruszać. Jednak jeśli podzielisz zegar na oddzielne komponenty — wskazówkę godzinową, minutową  i sekundową, wahadło oraz tarczę — znacznie łatwiej będzie Ci stworzyć zegar działający zgodnie z oczekiwaniami. Co więcej, jeśli przy budowie zegara wykorzystasz wiele różnych części, znacznie łatwiej będzie je wymieniać. Na przykład, jeśli wskazówka minutowa się złamie, to bez problemu będziesz mógł ją wymontować i zastąpić inną. Lub jeśli zostanie opracowane bardziej zaawansowane wahadło, będziesz mógł je wykorzystać w swoim zegarze oszczędzając tym samym zarówno czasu jak i pieniędzy.

Jest jednak jeden argument przemawiający przeciwko wykorzystywaniu komponentów. Otóż wykorzystanie zbyt wielu komponentów może przekreślić wszelkie korzyści poprzez zbytnie skomplikowanie aplikacji. Dlaczego niby miałbyś dzielić na części wahadło? Części działające dobrze jako jedna całość nie należy niepotrzebnie dzielić.

W kontekście ASP.NET komponenty są fragmentami kodu, który można wielokrotnie wykorzystywać w celu rozszerzenia możliwości aplikacji lub wzbogacenia jej o nowe funkcje. Elementy sterujące użytkownika o których pisałem w rozdziale 5. są właśnie przykładem komponentów. Także kod obsługi formularzy można traktować jako komponent. Nawet internetowe elementy sterujące są komponentami, których można używać przy tworzeniu stron ASP.NET. Komponenty są wykorzystywane w celu opisania istniejących obiektów, takich jak kalendarz bądź książka. W przypadku storn ASP.NET przykładami komponentów mogą być pola tekstowe bądź zbiory wyników pobrane z bazy danych.

Czym są obiekty biznesowe?

Nowe określenie

Obiekty biznesowe są komponentami zawierającymi kod wykorzystywany w tworzonej aplikacji. Kod udostępniający możliwości funkcjonalne niezwiązane z obsługą interfejsu użytkownika jest nazywany logiką biznesową lub regułami biznesowymi. A zatem, komponenty implementujące logikę biznesową są nazywane obiektami biznesowymi.

Na przykład, jeśli byś pisał aplikację prezentującą informacje pobierane z bazy danych, to cały kod związany z obsługą bazy i stanowiący warstwę pośrednią pomiędzy bazą a interfejsem użytkownika byłby logiką biznesową

Sens zdania musiał zostać zmieniony, gdyż w tłumaczeniu pomijane są rozdziały oryginału pt. „Week x in Review”.

. W optymalnym przypadku, kod stanowiący logikę biznesową powinien być oddzielony od strony ASP.NET i zaimplementowany w formie obiektu biznesowego. Strony ASP.NET powinny być wykorzystywane wyłącznie jako interfejs użytkownika i realizować przetwarzanie związane z obsługą „klienckiej” części aplikacji.

Bardzo popularny przykład obiektów biznesowych można spotkać na witrynach zajmujących się handlem elektronicznym, które muszą pobierać informacje o kosztach wysyłki od różnych firm przewozowych. Programista mógłby zaimplementować tę logikę w formie strony ASP.NET, lecz w takim przypadku, modyfikacja tej logiki w razie zmiany sposobu obliczania kosztów wysyłki byłaby znacznie utrudniona (nie wspominając w ogóle, o znacznie ograniczonych możliwościach wielokrotnego wykorzystania takiego kodu). Sprytniejszy programista mógłby natomiast stworzyć obiekt obliczający koszty wysyłki towarów, który można by wykorzystywać w dowolnych aplikacjach ASP.NET. Komponent ten pobierałby informacje o kosztach wysyłki z bazy danych firmy przewozowej i dostarczał aplikacji internetowej wszelkich koniecznych informacji. Komponent taki można by wielokrotnie wykorzystywać, a jakiekolwiek zmiany logiki biznesowej musiałyby być wprowadzane tylko w jednym miejscu, bez konieczności modyfikowania stron ASP.NET.

Dlaczego warto używać komponentów?

Być może słyszałeś o trójwarstwowym modelu aplikacji, w którym aplikacje są dzielone na trzy (czasami niezbyt rozdzielne) warstwy —prezentacji lub interfejsu użytkownika, logiki biznesowej oraz danych. Model ten z powodzeniem można wykorzystać przy tworzeniu aplikacji internetowych, a jego implementacja nie nastręcza zbyt wielu problemów. Trójwarstwowy model aplikacji został przedstawiony na rysunku 15.1.

Rysunek 15.1.              Trójwarstwowy model aplikacji składa się z warstwy interfejsu użytkownika, logiki biznesowej oraz danych

Opis rysunku

UI layer — Warstwa interfejsu użytkownika

ASP.NET pages…— Strony ASP.NET, elementy sterujące użytkownika, itp.

Bisiness objects — Warstwa obiektów biznesowych

Business rules … — Reguły biznesowe (logika biznesowa), pomocnicze możliwości funkcjonalne, itp.

Data layer — Warstwa danych

Database … — Baza danych, procedury zachowane, itp.

Trójwarstwowy model aplikacji przypomina nieco produkcję teatralną. Pierwszą warstwą są aktorzy występujący na scenie. Stanowią oni „interfejs użytkownika” dla widzów siedzących na widowni, przyciągając ich uwagę i dostarczając wrażeń. Z tą warstwą „aplikacji” mają kontakt widzowie oglądający przedstawienie.

Drugą warstwę stanowią osoby odpowiedzialne za produkcję przedstawienia i pomoc przy jego realizacji — orkiestra, osoby obsługujące scenografię, itp. Wszystkie te osoby prowadzą interakcję z aktorami występującymi na scenie, jednak pozostają niewidoczni dla publiczności. Osoby te kierują wykonaniem przedstawienia i dzięki nim aktorzy mogą odtwarzać swoje role.

I w końcu trzecią warstwę stanowią osoby odpowiedzialne za materia i scenografię — pisarze, artyści, scenografowie, i tak dalej. Wszystkie te osoby pracują wspólnie, aby nadać produkcji znaczenie. Publiczność nigdy ich nie widzi, dostrzega jedynie efekty ich pracy.

Ten model realizacji przedstawień jest doskonale zdefiniowany i dostosowany do konkretnych potrzeb. Wyobraź sobie co by się stało gdyby zabrakło jednej z jego „warstw”. Bez aktorów, w ogóle nie można by wystawić żadnego przedstawienia. Bez pisarzy i artystów nie byłoby czego wystawiać. Natomiast bez warstwy pośredniej — na przykład scenografów — aktorzy mieliby bardzo duże trudności z wykonywaniem swej pracy, a osoby zaliczające się do innej „warstwy” musiałyby zająć ich miejsce.

Ten sam model można zastosować przy tworzeniu aplikacji internetowych. Pominięcie jednej z warstw sprawa, że stworzenie aplikacji staje się o wiele trudniejsze. W przypadku witryn zajmujących się handlem elektronicznym, pierwszą warstwą jest interfejs użytkownika — formularze, „koszyki”, obrazy, itp. Pośrednia warstwa logiki biznesowej składa się z mechanizmów określających ceny towarów, koszty wysyłki, itd. I w końcu trzecia warstwa — warstwa danych — składa się z listy towarów przechowywanych w bazie danych. Jeśli którejkolwiek z tych warstw zabraknie, inna będzie musiała przejść jej funkcje.

Rozpatrując całe zagadnienie bardziej konkretnie, wykorzystanie obiektów biznesowych jako warstwy pośredniej pozwala na lepszą separację kodu oraz lepsze zdefiniowanie aplikacji. Dzięki nim, strony ASP.NET nie muszą już zawierać tajemniczego, długiego kodu, który w żaden sposób nie jest związany z interfejsem użytkownika. Przeznaczeniem tych stron jest wizualne przedstawianie informacji i przyciągnięcie uwagi użytkownika. Po co zatem umieszczać w nich kod, który z wizualną prezentacją informacji nie ma niczego wspólnego?

W porządku, właśnie tym zajmowaliśmy się w kilku ostatnich rozdziałach książki. Możliwości funkcjonalne, takie jak mechanizmy zapewniające dostęp do baz danych można umieścić w obiektach biznesowych zaliczanych do środkowej warstwy aplikacji. Jednak w wielu spośród przedstawianych przykładów, wykorzystywane możliwości funkcjonalne były tak proste, iż nie trzeba było implementować ich jako trzeciej warstwy i niepotrzebnie komplikować konstrukcji całej aplikacji. Obiekty biznesowe doskonale nadają się implementacji możliwości funkcjonalnych, które nie mają niczego wspólnego z interfejsem użytkownika. Niemniej jednak to Ty jako programista, musisz określić czy aplikacja jest na tyle skomplikowana, aby warto było wprowadzać do niej trzecią warstwę. Komponenty zapewniają także znacznie efektywniejszy sposób wykorzystania możliwości funkcjonalnych. Na przykład, przypomnij sobie kalendarz, przedstawiony w rozdziale 5, pt.: „Podstawowe wiadomości o tworzeniu formularzy internetowych”. Przy użyciu zaledwie kilku wierszy kodu, pozwala on na wyświetlenie w pełni funkcjonalnego kalendarza dostosowanego do wyglądu tworzonej aplikacji. Twórca strony nie musi się przejmować sposobem generacji kalendarza, wyświetlaniem poszczególnych tygodni, określaniem ilości dni w miesiącu, itp. Wszystkie te czynności są wykonywane za nas.

Komponenty należy tworzyć właśnie w taki sposób — tak, aby używający ich programiści nie musieli zaprzątać sobie głowy niewidocznymi sposobami działania komponentu. Wystarczy, że będą ich używać. Nawet jeśli się zdarzy, że użytkownik komponentu oraz jego twórca to ta sama osoba (czyli Ty), to wciąż komponenty są łatwym sposobem implementacji możliwości funkcjonalnych.

Nie należy także zapominać o oczywistych korzyściach jakie daje stosowanie komponentów. Dzięki nim wzrasta możliwość wielokrotnego wykorzystywania tego samego kodu, dzięki czemu aplikacje są mniejsze. Kompilacja komponentów niezależnie od stron ASP.NET zwiększa efektywność działania tych stron. Łatwiejsza jest także pielęgnacja aplikacji — zmiana logiki biznesowej w jednym miejscu będzie od razu zauważalna w całej aplikacji. A co więcej, tworzone komponenty są elementami środowiska .NET, co oznacza, że w razie konieczności można je rozbudowywać lub używać przy tworzeniu innych komponentów.

Niemniej jednak, zdarza się, że wydzielenie poszczególnych warstw aplikacji nie jest sprawą oczywistą. W jakim miejscu należy przeprowadzić linię podziału pomiędzy interfejsem użytkownika, a logiką biznesową? To pytanie programiści zadają już od jakiegoś czasu. Przykłady podane w tym rozdziale mają za zadanie, w możliwie największym stopniu, pokazać jak należy rozdzielać obie warstwy. Czasami jednak, zależy to wyłącznie od oceny programisty.

W jaki sposób ASP.NET korzysta z komponentów

ASP.NET przechowuje skompilowane obiekty w folderze /bin, nazywanym także pamięcią podręczną komponentów. Gdy czytając ten rozdział stworzysz przykładowe komponenty, to po ich skompilowaniu, umieścisz je właśnie w tym folderze. Obiekty zapisane w tym folderze są automatycznie ładowane podczas uruchamiania aplikacji ASP.NET. Właśnie dzięki temu będziesz mógł używać własnych komponentów w tworzonych stronach ASP.NET.

Istnieje także możliwość ręcznego załadowania obiektów, które nie są przechowywane w folderze /bin. W tym celu wykorzystywany jest plik konfiguracyjny web.config, jednak zagadnienia te wykraczają poza ramy tematyczne niniejszej książki. W większości przypadków, wszystkie argumenty będą przemawiały za tym, aby własne obiekty przechowywać w folderze /bin.

Po załadowaniu własnych obiektów, można z nich korzystać tak samo, jak z wbudowanych obiektów ASP.NET. Na przykład, przestrzeń nazw System oraz wszystkie dostępne w niej klasy zostały skompilowane w formie jednego pliku, przechowywanego w globalnej pamięci podręcznej komponentów. Podczas tworzenia stron ASP.NET można zaimportować przestrzeń nazw System, bądź też odwoływać się do klas za pomocą pełnych nazw, na przykład: System.Integer. Jak się przekonasz w dalszej części rozdziału, dokładnie w taki sam sposób można korzystać z własnych obiektów.

Tworzenie obiektów biznesowych

Tworzenie obiektów biznesowych do złudzenia przypomina tworzenie kodu obsługi formularzy. Obiekty takie to po prostu klasy stworzone w języku VB.NET (lub innym języku którym potrafisz się posługiwać) i zorganizowane w logiczne grupy.

Ale nie marnujmy czasu i zabierzmy się w końcu za stworzenie przykładowego obiektu biznesowego. Ogólny szablon takiego obiektu przedstawiony został na listingu 15.1.

Akapity w oryginale książki, na listingiem 15.1 są chyba nieco powtórzone i niezbyt sensowne.

Listing 15.1.              Podstawowa struktura obiektów biznesowych.

1           Imports System

2           Imports System.Data

3           Imports System.Data.OleDb

4            

5           Namespace TYASPNET

6            

7              Public Class Database

8              End Class

9             

10        End Namespace

Analiza

Zapisz ten plik pod nazwą Database.vb. Ten obiekt biznesowy zapewni nam ogólne możliwości funkcjonalne związane z obsługą baz danych, z których będziemy korzystać przy tworzeniu stron ASP.NET. Za pośrednictwem tego obiektu będziemy mogli nawiązać połączenie z bazą danych, wykonać zapytanie oraz pobrać uzyskane wyniki. Innymi słowy obiekt reprezentuje bazę danych i powinien mieć wszystkie właściwości i metody które definiują taką bazę.

Postać powyższego przykładu przypomina format zapisu kodu obsługi formularzy. W pierwszej kolejności są importowane przestrzenie nazw, które będą wykorzystywane w tworzonym obiekcie. W tym przypadku są to przestrzenie System, System.Data oraz System.Data.OleDb (importowane odpowiednio w wierszach 1., 2. oraz 3.). W wierszu 5. definiowana jest przestrzeń nazw do której będzie należeć tworzony obiekt. Skąd pochodzi nazwa ASPNETDK? Znikąd — utworzyliśmy ją właśnie w tej chwili. Na tym przykładzie widać jak łatwo można rozszerzać środowisko .NET — sama deklaracja użycia nowej przestrzeni nazw powoduje jej automatyczne utworzenie. Tworząc nowe obiekty na potrzeby aplikacji można je dodawać do tej samej przestrzeni nazw. A zatem, przestrzeń nazw stanowi logiczną grupę, zawierającą wszystkie wykorzystywane obiekty biznesowe.

Notatka
Na przykład, przestrzeń nazw System.Data.OleDb zawiera wiele klas, takich jak OleDbCommand, OleDbConnection czy też OleDbDataAdapter. Jak widać, przestrzenie nazw są używane do logicznego grupowania klas.

Gdybyśmy chcieli, moglibyśmy także podać nazwę już istniejącej przestrzeni nazw, na przykład System.Web. W takim przypadku tworzony obiekt zostałby dodany do tej przestrzeni. Należy jednak pamiętać, iż przestrzenie nazw służą do logicznego grupowania obiektów. Nasze przykładowe obiekty nie pasują do żadnej z istniejących przestrzeni, a zatem powinniśmy je umieścić w nowej, stworzonej specjalnie dla nich. Można tworzyć osobne przestrzenie nazw dla poszczególnych tworzonych aplikacji ASP.NET.

I w końcu, w 7. wierszu listingu 15.1, została umieszczona deklaracja klasy. Na razie jest ona pusta, jednak już wkrótce dodamy do niej właściwości i metody. Nie należy także zapomnieć o dopisaniu instrukcji zamykających deklarację klasy oraz przestrzeni nazw.

Skompilujmy nasz przykładowy obiekt biznesowy, abyśmy mogli go użyć w stronie ASP.NET. W tym celu wykorzystamy kompilator języka VB.NET dostarczany wraz z .NET SDK. Aby użyć kompilatora kliknij przycisk Start i wybierz opcję Uruchom. Następnie, w wyświetlonym okienku dialogowym wpisz cmd.exe i kliknij przycisk OK — na ekranie pojawi się okno interpretera poleceń. Pierwszą czynnością  jaką będziesz musiał teraz wykonać, jest przejście do głównego folderu aplikacji (w naszym przypadku jest to C:\inetpub\wwwroot\aspnetdlakazdego) i utworzenie folderu bin. W tym celu należy wydać polecenie:

mkdir bin

Za chwilę w tym folderze umieścimy nasz przykładowy obiekt biznesowy. Teraz przejdź do folderu w którym zapisałeś kod źródłowy tworzonego obiektu, na przykład: C:\inetpub\wwwroot\aspnetdlakazdego\rozdzial15. Następnie wpisz poniższe polecenie i naciśnij klawisz Enter:

vbc /t:library /out:..\bin\ASPNETDK.dll /r:System.dll /r:System.Data.dll

   Database.vb

Kompilator języka VB.NET ma wiele opcji i jest bardzo skomplikowany; dlatego też omówimy tu wyłącznie opcje użyte w powyższym poleceniu. (Istnieje duże prawdopodobieństwo, że pisząc aplikacje ASP.NET nie będziesz musiał używać żadnych innych opcji.)

vbc.exe to nazwa kompilatora języka VB.NET. Program ten posłuży nam do skompilowania naszego przykładowego obiektu biznesowego do postaci biblioteki DLL, która będzie wykorzystywana w aplikacji ASP.NET. Parametr /t określa typ wynikowego pliku, który ma zostać utworzony. Library oznacza, że utworzony zostanie obiekt, który będzie mógł być wykorzystywany przez inne aplikacje, ale nie samodzielnie jak inne programy. Parametrowi /t można także przypisać wartość exe, co spowoduje wygenerowanie standardowego pliku wykonywalnego.

Parametr /out określa folder oraz nazwę pliku, w którym zostaną zapisane wyniki działania kompilatora. W naszym przypadku, wygenerowana biblioteka DLL ma zostać umieszczona w folderze /bin, a zatem, w parametrze /out podaliśmy względną ścieżkę dostępu do tego folderu oraz nazwę wynikowego pliku. Parametr /r oznacza odwołanie. W naszym przykładowym obiekcie biznesowym odwołujemy się do trzech przestrzeni nazw — System, System.Data oraz System.Data.OleDb. Przestrzeń nazw System została zapisana w pliku System.dll, natomiast pozostałe dwie przestrzenie — System.Data oraz System.Data.OleDb — w pliku System.Data.dll.

Ostrzeżenie
Pamiętaj, aby określać odwołania w poleceniu uruchamiającym kompilator a nie ograniczać się do instrukcji Import w kodzie źródłowym programów. Bez tych odwołań, polecenia Import nie będą miały żadnego znaczenia, a przy próbie kompilacji pliku pojawią się błędy.

Ostatnim elementem powyższego polecenia jest nazwa kompilowanego pliku — Database.vb. To właśnie ten plik zostanie skompilowany i umieszczony w pamięci podręcznej komponentów, gdzie będzie dostępny dla tworzonych stron ASP.NET. Wyniki kompilacji kodu z listingu 15.1 zostały przedstawione na rysunku 15.2.

Rysunek 15.2.              Użycie kompilatora języka VB.NET do tworzenia obiektów biznesowych

Notatka
Nie przejmuj się, jeśli nie jesteś w stanie wprawnie posługiwać się kompilatorem VB.NET. Zazwyczaj będziesz musiał posługiwać się jednym i tym samym poleceniem, a jeśli jego składnia będzie musiała ulec zmianie — wyraźnie zaznaczę to w tekście. Więcej informacji na temat tego programu znajdziesz w dokumentacji .NET SDK.

Na listingu 15.2 przedstawiony został kod strony, która będzie korzystać z naszego przykładowego obiektu biznesowego.

Listing 15.2.              Wykorzystanie obiektu biznesowego na stronie ASP.NET.

1           <%@ Page Language="VB" %>

2            

3           <script runat="server">

4              sub Page_Load(obj as object, e as eventargs)

5                 dim objDatabase as ASPNETDK.Database

6                 lblMessage.Text = "Obiekt został pomyślnie utworzony!"

7              end sub  

8            

9           </script>

10         

11        <html><body>

12           <asp:Label id="lblMessage" runat="server" />

...