Architektura oprogramowania – jak zaprojektować aplikację

Jest kilka cech charakteryzujących dobrze zaprojektowaną aplikację.

Architektura oprogramowania powinna być:
– skalowalna
– warstwowa
– modułowa
– czytelna
– łatwa w utrzymaniu

Aplikacja skalowalna oznacza, że zaprojektowana architektura radzi sobie równie łatwo z 100 000 użytkowników jak z setką. Wzrost obciążenia nie powoduje znacznego spadku wydajności.

Warstwy dzielą całą aplikację na kilka różnych poziomów, z których każdy jest niezależny i może zostać podmieniony przez inny. Np. warstwa bazy danych może zostać podmieniona z MySQL na Oracle, a reszta aplikacji wciąż działa poprawnie.

Modułowość pokrywa się trochę z warstwowością. Jednak chodzi bardziej o wyodrębnienie funkcjonalności na konkretnej warstwie. Np. osobnym modułem może być logowanie zdarzeń do pliku, które może być dołączone do dowolnej warstwy. Równie łatwo może być odłączone, nie powodując zachwiania funkcjonowania całego systemu.

Czytelność. Zarówno w kwesti kodu, nazewnictwa i struktury katalogów i plików. Projekt musi być zrozumiały dla osób dołączających do teamu projektowego i przystosowany do szybkiego wdrożenia.

Łatwość w utrzymaniu aplikacji mówi samo za siebie. Jest to np. jasny mechanizm logowania kluczowych akcji, błędów i wyjątków. Jeśli pojawi się bug po wypuszczeniu apki w świat, musi być łatwo identyfikowalny i naprawialny.

Na pewno znajdziesz mnóstwo innych kwesti, na które należy zwracać uwagę. Te jednak posłużą Ci za dobry punkt wyjścia.

Na nich oprzemy się przy projektowaniu własnej architektury aplikacji.

A skupimy się głównie na prawidłowym podzieleniu oprogramowania na warstwy…

Podczas nauki programowania zazwyczaj wrzucamy kod do jednego pliku. W przypadku PHP nie trzeba było nawet tworzyć obiektów.

Linijka po linijce, to co sobie napisaliśmy, wykonywało się sekwencyjnie.

Tworzyłeś zapewne połączenie z bazą, odbierałeś dane z zapytania SQL, tworzyłeś sobie zmienne w programie na podstawie odebranych danych itd.

Wszystko działało.

Na potrzeby stworzenia sobie drobnej stronki z formularzem kontaktowym to podejście w zupełności wystarczy.

Jeśli jednak planujesz zbudować dużą, porządną aplikację. Niezawodną aplikację. Potrzebujesz poznać zasady tworzenia architektury oprogramowania.

Warswy aplikacji – z czym to się je

Jak wygląda warstwa?

Ile warstw powinna mieć moja aplikacja?

Nie ma idealnej odpowiedzi na to pytanie. Najlepiej, żeby aplikacja miała co najmniej 3 warstwy:
– warstwa obsługi Bazy Danych
– warstwa dostępu do danych (Data Access Layer lub DAL)
– (opcjonalnie) warstwa serwisów (Service Layer)
– warstwa prezentacji (klient)

W idealnym świecie cała obsługa bazy danych powinna znajdować się w osobnym projekcie, który jest jedynym punktem styczności między bazą a resztą aplikacji. Tutaj znajdują się sprawy związane z konfiguracją i nawiązaniem połączenia oraz wykonywaniem zapytań na bazie.

Drugą warstwą jest DAL. Dostęp do danych. Warstwa ta ma za zadanie tłumaczyć dane bazy danych na obiekty biznesowe. W obie strony. Do bazy i z bazy.

Warstwa serwisów wystawia na zewnątrz możliwe metody, które angażują Data Access Layer i umożliwiają ich wykorzystanie z warstwy klienta. Umożliwia to oddzielenie logiki biznesowej od warstwy klienta. Jeśli operacje wymagają bardziej skomplikowanej logiki przetwarzania, często dodaje się w tym miejscu nową warstwę – (Business
Logic Layer lub BLL).

Celowo oznaczyłem tę warstwę jako opcjonalną, gdyż często zdarza się łączenie warstwy serwisów i DAL w jedną. W przypadku mniej skomplikowanych projektów jest to w zupełności wystarczające.

Warstwa prezentacji to punkt styczności między użytkownikiem a aplikacją. Tutaj może się znaleźć witryna internetowa, aplikacja okienkowa (desktopowa), aplikacja na urządzeniu mobilnym itp.

Dzięki takiemu oddzieleniu warstw, klient korzysta jedynie z wystawionych metod przez warstwę serwisów. W ten sposób możemy mieć kilka aplikacji klienckich, które korzystają z dokładnie tego samego zestawu metod.

W ten sposób osiągnęliśmy następujące korzyści:

– Baza danych to niezależny projekt, który może zostać podmieniony w razie potrzeby. Jeśli zajdzie taka konieczność, można nawet całkiem zrezygnować z bazy danych na rzecz plików (choć nie życzę nikomu takiego scenariusza). Reszta warstw wciąż widzi bazę danych tak, jak widziała wcześniej.

– Warstwa dostępu do danych to jedyne miejsce, które przekształca dane z bazy na obiekty w programie. W razie konieczności można zmodyfikować algorytm (np. dodatkowo obliczyć wiek pacjenta na podstawie jego daty urodzenia i zwrócić go jako dodatkowe pole w obiekcie) nie naruszając struktury bazy danych ani działania wyższych warstw.

– Warstwa serwisów reguluje możliwą interakcję między klientem a danymi. Metodami, które udostępnia serwis są np. 'Dodaj nowego pacjenta’, 'Pobierz wszystkich pacjentów’ itp. Klienci aplikacji mogą korzystać jedynie z metod wystawionych przez serwisy.

– Warstwa kliencka (prezentacji) to ostateczny punkt styczności między użytkownikiem a resztą aplikacji. Aplikacji klienckich może być wiele, dla różnych urządzeń. Możesz również udostępnić metody swojego serwisu na zewnątrz, wystawiając tzw. API. Umożliwisz wtedy każdemu na tworzenie własnych klientów do Twojej aplikacji.

Podsumujmy…

Taki podział funkcjonalny na proponowane warstwy to bardzo dobry punkt wyjścia.

Oczywiście, jeśli uznasz, że wypadałoby dodać inne warstwy, nie wahaj się. Zazwyczaj będzie to dobra decyzja.

Wystarczy popatrzyć na przykładowy Stack Trace z aplikacji .NET lub JAVA.

 

Nie każda linijka reprezentuje nową warstwę, jednak widać tutaj jasno głęboki poziom abstrakcji. Zanim wyjątek dotarł do warstwy prezentacji, przeszedł przez te wszystkie metody.

Przykład stack trace’a Javy pochodzi ze strony WIKI SAPa http://wiki.scn.sap.com/. Pierwszy lepszy, jaki udało mi się znaleźć w Google Images.

Możesz zawsze na niego zerknąć, jeśli stwierdzisz, że za bardzo zagnieżdżasz się w swoim kodzie.

Naprawdę ciężko jest przesadzić w zagnieżdżeniu.

Dlatego śmiało dopisz kolejną warstwę abstrakcji i bądź z siebie dumny.