Warstwy aplikacji

PODZIAŁ WARSTW APLIKACJI, DLACZEGO?

Profesjonalne aplikacje komputerowe są podzielone na warstwy: warstwę prezentacji, biznesową i danych. Taki podział aplikacji uniezależnia wygląd aplikacji od jej wewnętrznych obliczeń (tzn. warstwy biznesowej) oraz sposobu przechowywania danych.

Wyobraźmy sobie, że postanawiasz napisać program komercyjny i ściśle wiążesz go z komponentami wizualnymi. Niech to będzie program do fakturowania. Po naciśnięciu przycisku Nowa Faktura otwierasz okienko i pozwalasz użytkownikowi wpisać wszelkie dane. Źle zaprojektowany program  będzie miał w przycisku ZAPISZ cały kod odpowiedzialny za sprawdzenie poprawności formularza oraz połączenie z bazą danych i wysłanie do niej operacji INSERT/UPDATE.

Gdyby program korzystał ze zdalnego serwera i wystąpił problem z połączeniem internetowym wyrzuci mnóstwo błędów. Gdyby nasz zleceniodawca zarządał teraz wprowadzenie do programu automatycznego importu faktur dostarczonych w inny sposób, np. za pomocą pliku Excel będziemy zmuszeni skopiować nasz kod z wnętrza przycisku ZAPISZ, troszkę przerobić i wkleić w miejsce gdzie importujemy faktury. A jeśli za pół roku okaże się że powinien jeszcze importować faktury w inny sposób? Powoli staniemy się więźniami naszej aplikacji. Każda zmiana lub dodanie nowych pól do faktury będzie wymagała zmian w wielu miejscach kodu. To się po prostu nie opłaca.

Po kilku latach taki projekt wymaga przeprojektowania. Oczywiście możemy obwiniać zleceniodawcę, dlaczego nie powiedział wcześniej co planuje. Ale zleceniodawca też zazwyczaj nie wie jak zmienią się wymagania w następnych latach.  Programiści często nazywają kod takich projektów kodem Spaghetti. Wszystko jest wymieszane. Operacje bazodanowe oraz logika programu nie powinny być wbudowane w te same klasy.

To jak powinno być?

Wyobraź sobie, że Twoja aplikacja to 3 czarne skrzynki, które mają pewne guziki i złącza. Nie widzisz dokładnie co jest w środku. Po prostu ufasz, że każda ze skrzynek dobrze wykona swoją pracę i po wciśnięciu odpowiednich guzików lub podpięciu złączy będzie współpracować z innymi skrzynkami. Skrzynki mogłyby więc być podmieniane na inne i dostarczane przez inne firmy. Taka jest ideologia. Nie zawsze wychodzi to tak łatwo. Ale spróbujmy to omówić.

WARSTWA DANYCH

Warstwa danych jest obecnie projektowana za pomocą dowolnego silnika bazodanowego. Do programisty należy jedynie zaprojektowanie odpowiedniej struktury tabel.

Czy warto tworzyć własny silnik bazodanowy? Jeśli nie masz zbyt skomplikowanych wymagań oczywiście możesz. Własny silnik bazodanowy może być bardzo szybki. Ale raczej nie będzie elastyczny. Własne silniki bazodanowe z reguły zajmują się wyspecjalizowanymi zadaniami dla niecodziennych zastosowań lub szybkim podawaniem prostych danych.

Mnóstwo wyspecjalizowanych programistów pracowało latami nad utworzeniem świetnych powszechnych silników bazodanowych, jak np. Microsoft SQL Server. Trudno oczekiwać, że w pojedynkę napiszesz coś bardziej profesjonalnego. Jeśli zaczynasz przygodę z programowaniem, lepiej będzie dobrze poznać konkretny silnik bazodanowy i polegać na nim.

Jak aplikacja rozmawia z warstwą danych? Oczywiście silniki bazodanowe zawierają całą specyfikację oraz dostarczają biblioteki, za pomocą których możesz z nimi rozmawiać. Np. OleDB pozwala na tworzenie połączeń, a potem wykonywanie operacji. Ale lepiej nie wiązać się na sztywno z takimi bibliotekami.

Jest wiele sposobów na rozwiązanie tego zagadnienia. Najbardziej profesjonalne polegają na oddzieleniu bibliotek dostawcy danych od warstwy biznesowej. W tym celu tworzy się repozytoria, czyli osobne klasy, których jedyne zadanie to wydobyć dane albo przesłać UPDATE. Te klasy mogą korzystać z bibliotek bazodanowych. Dobrze by było, gdyby warstwa biznesowa „nie wiedziała” o użytych bibliotekach, może natomiast znać repozytoria lub zwracane obiekty.

WARSTWA BIZNESOWA

Nazwa biznesowa wcale nie musi się odnosić do biznesu. Tak po prostu się nazywa z uwagi na to, że większość aplikacji jest poświęcona biznesowi. Celem tej warstwy jest zapewnienie poprawności obliczeń. Warstwa ta przeprowadza wszelkie transakcje, sprawdzanie poprawności formularzy, buduje logikę całego programu. Może a nawet powinna udostępniać interfejsy lub inne metody dostępu do aplikacji.

Jeśli więc mamy do napisania aplikacje do fakturowania, czym zajmie się warstwa biznesowa? Może udostępniać strukturę HTTP do importu faktury. Następnie sprawdzi czy wszystkie pola zostały prawidłowo wypełnione i zwróci komunikat do wysyłającego polecenie. Dzięki takiemu podejściu otrzymujemy tylko jeden sposób na dodawanie faktur. Gdy nasza aplikacja otrzyma nowe wymagania, łatwo będzie skorzystać z gotowego systemu warstwy biznesowej by dodać fakturę w jeszcze inny sposób.

Jeśli nasza aplikacja nie posiada serwera HTTP, czyli to typowa aplikacja kliencka, warstwa biznesowa może udostępniać interfejsy informujące programistę warstwy prezentacji o możliwych operacjach.

WARSTWA PREZENTACJI

Obejmuje wizualne komponenty aplikacji, layout oraz proste operacje przesyłania danych pomiędzy widokami i obsługę błędów. Warstwa prezentacji musi również wydawać polecenia do warstwy biznesowej. Jeśli użytkownik naszego programu kliknie Nowa Faktura, warstwa prezentacji wyświetli formularz do wpisania danych faktury. Co więc zrobi warstwa prezentacji gdy użytkownik kliknie ZAPISZ?

Po prostu zbuduje obiekt, który dla przykładu nazwiemy: CreateInvoiceRequest i prześle go do warstwy biznesowej. Następnie sprawdzi rezultat operacji i poinformuje użytkownika o poprawnym dodaniu faktury lub poinformuje go o błędach w przesyłanym formularzu.

Gdzie się tworzy taką warstwę? Jedni wbudowują warstwę biznesową jako procedury serwera SQL. To nie jest najlepsze rozwiązanie, ponieważ klient będzie znał hasło do naszego serwera. Jeśli źle ustawimy uprawnienia, może łatwo włamać się do naszej bazy i wykraść dane. Jeszcze gorzej jest w wypadku aplikacji klienckich z wbudowaną warstwą biznesową w siebie. Taka aplikacja także może zostać szybko rozpracowana. W chwili obecnej najlepiej zbudować osobną aplikację z serwerem HTTP. Warstwa biznesowa umieszczana jest na serwerze więc klient nie będzie miał możliwości dostępu do danych inaczej jak przez naszą warstwę biznesową. Oczywiście tutaj też ważną rolę gra świadome budowanie aplikacji pod kątem bezpieczeństwa, ale to podejście daje największe możliwości.

PODSUMOWANIE

Oddzielenie aplikacji na warstwę danych, biznesową i prezentacji początkowo komplikuje budowę i wydłuża czas projektowania aplikacji. Wymaga również starannego planowania interakcji pomiędzy warstwami. Przestaje to mieć sens w początkowych projektach edukacyjnych gdy uczymy się podstaw programowania. Ciężko jest od razu przeskoczyć z początkującego w profesjonalny tryb tworzenia aplikacji.

Zalet jest mnóstwo: czytelność kodu, przejrzystość ogólna projektu, łatwość dodawania nowych możliwości, szybkie zmiany wizualne, lepsze możliwości współpracy z innymi dostawcami danych, krótszy kod warstwy prezentacji. Długość życia takich aplikacji będzie większa niż aplikacji typu Spaghetti.