UI Layer, Business Layer, Data Layer

0

Witam.
Naczytalem sie sporo ostatnio o tym jak to dobrze rozdzielic logike aplikacji i nie trzymac wszystkiego w w layerze prezentacji. Nie znalazlem jednak zadnych przykladow z "zycia wzietych".

Chetnie zastosowalbym to rozwiazanie w swoim projekcie, nie wiem tylko jak ma to praktycznie wygladac. Domyslam sie, ze rozne warstwy to po prostu rozne klasy, ktore to zajmuja sie tylko wybrana dziedzina.

Moze ktos, kto wykorzystuje tego typu architekture moglby przyblizyc mi na jakims prostym przykladzie jak wyglada to w praktyce.

Pytalem juz o to na forum msdn'u ale bez echa.

Bylbym wdzieczny za jakakolwiek pomoc.

Mariusz

0

Przyjrzyj się modelom MVC, gdzie Viewer odpowiada UI Layer, Controller odpowiada Business Layer, a Model odpowiada Data Layer (właściwie Data Layer oraz Data Access Layer).

Prosty przykład (spore uproszczenie, mające na celu pokazać ideę):

Załóżmy, że dane trzymasz w bazie danych lub plikach. Budujesz klasę (najczęściej jedną dla każdego źródła danych). Klasa ta na zewnątrz udostępnia tylko metody do korzystania z danych, bez względu na ich źródło. Tylko ona ma prawo wywołać powiedzmy polecenia SQL czy dostać się do plików - właściwie tylko ona powinna wiedzieć, że korzystasz z BD czy plików. To jest twój Data (Access) Layer.

Następnie tworzysz klasę (lub kilka klas) kontrolerów. Obiekt kontrolera łączy w sobie menadżera interakcji z innymi systemami (na przykład obsługa gniazd sieciowych) oraz obsługę zdarzeń tak systemu, jak i samego interfejsu użytkownika. Z zewnątrz zatem wpływają do niego zgłoszenia zdarzeń, na zewnątrz eksponuje tylko stan systemu. Stanem może być na przykład blokowanie okna głównego i pokazanie okna połączenia bez względu na to, jak wyglądają te okna i jaka jest ich klasa). Ważny jest tylko interfejs klasy UI Layer, by udostępniał takie funkcjonalności lub samodzielnie korzystał z interfejsu kontrolera.

Ostatnia grupa klas to UI Layer. Większość środowisk RAD tworzy ją automatycznie, generując dla każdej formy osobne okno. Podstawowa jednak różnica wynika z tego, że środowiska te chcą łączyć w sobie zarówno Viewer, jak i Controller, gdyż sugerują obsługę zdarzeń w ramach samej formy.

Rozwiązaniem powyższego problemu jest, w ramach obsługi zdarzeń, wywołanie metody obiektu odpowiedniego w danej sytuacji kontrolera, a na podstawie zwróconego przez niego stanu ustawienie wyglądu.

Podmieniając Data Layer na inny o tym samym interfejsie, jesteś w stanie zmienić dostawcę danych, bez modyfikowania działania aplikacji. Zmieniając UI Layer jesteś w stanie dostosować wygląd GUI bez zmiany działania aplikacji. Business Layer jest tu kluczową częścią, bo decyduje o formie przetwarzania danych i jego zmiana de facto zmienia aplikację. Warstwa logiki biznesowej rzadko zatem jest całkowicie zmieniana, natomiast rozszerzanie jej pozwala na pracę nad programem, który wciąż wygląda tak samo, wciąż korzysta z tych samych danych, a ma już zaimplementowane (choć jeszcze ich nie eksponuje) nowe funkcjonalności.

0

Bardzo fajny opis problemu.
Czy to jedyna sluszna droga... architektura? n-tier layer?

Dzieki za odpowiedz. Wyglada jednak, ze taki schemat bardzo komplikowalby mi program.
Business Layer przeciez moze potrzebowac roznorakiego rodzaju danych, rowniez odbieralby wyniki od Data layer roznych rodzajaw. Musialbym oprogramowac kazde mozliwe rozwiazanie.
To samo sie tyczy UI Layer. Nie wyglada mi to specjalnie atrakcyjnie.

Pozdrawiam
Mariusz

ps. przyjze sie MVC

0

To nie jest jedyna droga. Architektury n-tier oraz MVC nie są tożsame. Zgodnie z MVC możesz zbudować powiedzmy aplikację ASP czy PHP (oddzielisz funkcjonalność, dostęp do danych i wygląd), ale będzie to wszystko zrealizowane w środkowej warstwie modelu trójwarstwowego.

Niższą warstwę będzie stanowił serwer baz danych (z któym będzie miał kontakt Model), a wyższą cienki klient w postaci przeglądarki (z którym będzie miał kontakt Viewer). MVC to raczej wzorzec projektowy dla aplikacji, kiedy z kolei n-tier to architektura systemu złożonego z tej i dodatkowych aplikacji specjalizowanych do zadań przechowywania danych, obliczeń lub obsługi interfejsu użytkownika.

Często MVC jest porównywane do n-tier, gdyż w tej drugiej zależności są stricte warstwowe, a nie wzajemne jak w MVC. Jednak tworzenie całej aplikacji wykorzystującej wyłącznie n-tier nie jest do końca popularne, tak samo jak wdrażanie aplikacji w system o architekturze MVC.

DOPISANE: Może źle się wyraziłem: piszesz klasę modelu nie dla każdego źródła danych osobno, ale dla każdego rodzaju źródła danych. Na przykład masz osobną klasę do obsługi MS SQL, osobną dla Oracle, osobną dla XML, a jeszcze osobną dla własnych plików binarnych. Oczywiście taką metodę tworzenia znacznie ułatwiają deklaracje interfejsów czy dziedziczenie, ale to już pozostaje w gestii programisty.

Także nie jest tak do końca, że Data Layer będzie potrzebował wiele możliwości (chyba, że robisz aplikację specyficzną).

Inne podejścia, oprócz n-tier oraz MVC to, wywodzący się z Java, popularny w prostych aplikacjach webowych Model 1 (Model 2 to MVC w tych zastosowaniach), PAC (Presentation, Abstraction, Control), HMVC (Hierarchical MVC) czy TeMP (Template Method Patern).

0

Dziekuje za wyczerpujace informacje.
Obawialem sie, ze nie uzywajac n-tier robie blad, poniewaz kazda powazna aplikacja powinna taki schemat wspierac. To dobrze wiedziec, ze to nie jedyna sluszna droga.

Przy okazji szukania wpadlem na swietny tutorial odnosnie architektury aplikacji .NET

Pozdrawiam
Mariusz

http://msdn2.microsoft.com/en-us/library/ms954595.aspx

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0