Postanowiłem, że zanim przejdę do omawiania kolejnych warstw systemu, wyjaśnię bardziej szczegółowo po co wprowadzono trójwarstwowy model aplikacji wspomniany w poprzednim poście. Otóż dzięki separacji kodu na warstwy nasza architektura stanie się elastyczniejsza. Model umożliwi nam m.in.:
-
Przenośność. Kolejne warstwy będą mogły być rozmieszczane na różnych platformach sprzętowych. W każde chwili będziemy mogli np. przenieść warstwę biznesową na zewnętrzny serwer, bez konieczności modyfikowania kodu, Dzięki niezależności warstwy prezentacji od warstwy biznesowej stanie się to bardzo proste w realizacji.
-
Redukcja zbędnych powiązań między klasami – model definiuje, że warstwa może odwoływać się wyłącznie do warstw znajdujących się bezpośrednio pod nią. Warstwa prezentacji może wywoływać wyłącznie warstwę biznesową(lub usług w przypadku modelu rozszerzonego), warstwa biznesowa z kolei powinna odwoływać się tylko do warstwy dostępu do danych. Sytuacja, w której warstwa biznesowa posiada referencję do warstwy prezentacji jest niedopuszczalna.
-
Skalowalność – dzięki rozdzieleniu kodu łatwo można zaimplementować np. mechanizm load balancing(równoważenie obciążenia).
-
Łatwiejsze testy integracyjne. O metodykach testów integracyjnych w szczegółach napiszę innym razem. Ogólnie chodzi o przetestowanie połączeń między modułami. W przypadku gdy mamy podzielony system na warstwy, biblioteki łatwiej jest nam zdefiniować te połączenia. Ponadto każdą warstwę można zastępować tzw. obiektem mock (obiekt naśladujący prawdziwy obiekt, ale tak naprawdę nie zawierający żadnej logiki – zwraca na sztywno określone wyniki).
Kolejną istotną sprawą w modelu trójwarstwowym jest zdefiniowanie połączeń między warstwami czyli określenie w jaki sposób warstwy będą komunikować się ze sobą. W najprostszym przypadku będzie to po prostu lokalne wywołanie klas. W systemach enterprise, często moduły są rozproszone i istnieje wiele sposób komunikacji. O to schemat rozszerzony o kilka możliwych protokołów komunikacji:
TDS to protokół komunikacji z bazą danych (Tabular Data Stream). Zdefiniowanie protokołów zależy już od konkretnej aplikacji. Powyższy rysunek to tylko prosty przykład. Ważniejszy jednak jest kierunek strzałek ponieważ określa on referencję między warstwami – warstwa może wywoływać kod wyłącznie warstwy znajdującej się bezpośrednio pod nią.
W następnym poście zamierzam zacząć opisywanie warstwy biznesowej. Prawdopodobnie będzie to wstęp teoretyczny do tej warstwy oraz pierwszy wzorzec projektowy – skrypt transakcji. Zapraszam!
‘Przenaszalność’ – mysle ze bardziej odpowiednim slowem byloby ‘przenośność’
“Przenaszalność” – częściej chyba używa się “przenośność”.
“Sytuacja, w której warstwa biznesowa posiada referencję do warstwy prezentacji jest niedopuszczalna.” – pogrubiłbym, użył większej czcionki. Widuję sytuacje kiedy warstwa prezentacji korzysta z modelu danych. Strasznie trudno się poprawia i optymalizuje takie malutkie haki ;] które wynikły na wskutek tego że czasami logiczne przetłoczenie czegoś(f przez trzy warstwy jest dość czasochłonne.
Dzięki za sugestie;)Poprawiłem.
“Kolejne warstwy będą mogły być rozmieszczane na różnych platformach sprzętowych” – to wszystko ładnie wygląda w teorii ale praktyka wykazuje, że taki podział może być strasznie niewydajny. I co gorsza, jest niewydajny. W kilku projektach, w których biorę udział dążymy do tego aby nie rozdzielać sprzętowo różnych warstw bo komunikacja pomiędzy podsystemami zabija platformy, na których to działa.
Zależy od projektu – warstwę biznesową często oddziela się od warstwy prezentacji, przykład to choćby ta strona 😉
Chodzi mi o to, że jak oddzielisz jawnie kod łatwo potem przenieść warstwę biznesową na inny komputer i uzyskiwać dostęp do niej np. przez przeglądarkę. Z kolei warstwa dostępu do danych może być na tym samym sprzęcie co warstwa biznesowa no chyba, że używamy rozproszonych baz danych.