2277150880

Architektura trójelementowa

Pierwsza warstwa jest odpowiedzialna za interakcje z użytkownikiem. Zawiera ona elementy interfejsu graficznego użytkownika. Warstwa ta jest bardzo mocno zintegrowana i zależna od środowiska programistycznego.

Druga warstwa składa się z elementów związanych z problemem. Jest to warstwa odpowiedzialna za odwzorowanie modelu. Model ten powstaje w wyniku analizy wymogów strukturalnych systemu informatycznego - czyli wcześniej wspomnianego schematu. Warstwa ta składa się z obiektów logiki biznesowej (odpowiedzialnych za realizację zagadnień z dziedziny problemów projektu) i obiektów sterujących (obiektów odpowiedzialnych za sterowanie aplikacją).

Trzecia warstwa jest odpowiedzialna za nawiązanie i realizację połączenia z danymi. Ma za zadanie umożliwić dostęp do danych zapewniając jednocześnie stabilny, spójny i jednolity dostęp do danych. Warstwa ta jest silnie związana ze środowiskiem programistycznym i plikami, albo bazami danych. Ta warstwa często jest teoretycznie dzielona na elementy zaprogramowane przez developera i na elementy sterowników (ODBC lub JDBC) oraz bibliotek dostępu do danych.

Rozwiązanie dobrze zbudowane w idei architektury trój warstwowej charakteryzuje się słabymi związkami pomiędzy elementami. Słabe związki należy rozumieć jako możliwie najmniejszą zależność pomiędzy warstwami. Czyli im mniej kodu w pozostałych warstwach trzeba będzie zmienić wymieniając element lub elementy danej warstwy, tym związek jest słabszy - rozwiązanie jest wtedy bardziej elastyczne. Następstwem słabych związków jest słabszy wpływ jednej warstwy na drugą.

Stosuje się również rozwiązania jednowarstwowe. Przykładem może być MS Acces, w którym wszystkie składniki systemu mogą funkcjonować w jednym module.

W celu lepszego zrozumienia idei warstwy zastanówmy się nad poniższym przykładem. W firmie obsługującej wielu klientów funkcjonuje system bazodanowy, który powstał 3 lata temu. Dział informatyczny zostaje zobligowany do zmiany systemu bazodanowego z Microsoft SQL Server na MySQL. Im zależności pomiędzy warstwą dziedziny problemu, a warstwą danych są słabsze tym mniej pracy będzie do wykonania. W tym przypadku, przy dobrze zaprojektowanym systemie, wystarczy, że programiści wymienią biblioteki baz danych i przejrzą kod pod względem zgodności zapytań starej bazy danych z nową.

Najbardziej dopracowane rozwiązanie umożliwia wymianę nawet całej warstwy bez wpływu na pozostałe.

Podsumowując, tworzenie aplikacji w architekturze trój warstwowej jest bardziej pracochłonne, niż programowanie bez warstw, czy technik RAD. Stworzenie koncepcji jest trudniejsze, ale daje kilka korzyści:

- kod i projekt mają łatwą do czytania strukturę. Gdy każda warstwa skoncentrowana jest na jednym aspekcie łatwiej zarządza się kodem - konserwacja i modyfikacja projektu jest łatwiejsza,

„Projekt współfinansowany ze środków Europejskiego Funduszu Społecznego"