Luźne rozważania na temat N-tier

Ostatnio miałem pewne problem z architekturą w projekcie i podziałem klas między projektami.
Zauważyłem, że jest to bardzo subiektywny temat dla różnych programistów.
Chciałbym uchwycić skąd pochodzi to subiektywne podejście. Takie "brain dump", może bez sensu.

--

Wszystkie obiekty są równe. Jedne rodzą się biedne a drugie bogate, jedne są mądre a drugie nie. :)
Każdy ma swoją matkę "fabrykę", Ona je rodzi.
Dla obiektu nie ma znaczenia w jakim miejscu istnieje jego rodzic (np. IoC, fabryka, builder, singleton).

Kod genetyczny każdego obiektu (np. IL) musi być gdzieś umieszczony. 
U ludzi kod jest w rodzicach. Ale rzeczy na świecie powstają z innych źródeł.
Obraz na telewizorze ma swój kod z satelity w kosmosie. Chleb z wiedzy piekarza. UIElement z XAMLa.
To gdzie kod genetyczny obiektu jest umieszczony nie zmienia jego celu, wyglądu ani zachowania.
Być może dlatego nie ma znaczenia gdzie kod klasy będzie umieszczony.

Jedyne co różni obiekty to cel w jakim mogą zostać użyte. 
Celów są tysiące. Według SOLID każdy obiekt ma wyłącznie jeden cel (S -> responsibility).

Obiekty czasem używamy wspólnie, aby tworzyć kompozyty.
Nie chce nam się za każdym razem wybierać ręcznie zestawu zależności (np. klas składowych). 
Dlatego referencjonujemy całą bibliotekę, więcej niż potrzebujemy.
Może tu jest cały problem. Ale to rozważania na inny moment.

Żeby sobie ułatwić życie ludzie zaczęli grupować obiekty w biblioteki. I tu jest kłopot :)
Każdy zestaw obiektów można pogrupować na kombinatoryczna ilość grup.
Po jednej stronie ekstremum mamy jedną grupę/bibliotekę z wszystkimi typami, po drugiej stronie grupy z wyłącznie jednym elementem.

Z drugiej strony chcemy sobie grupowaniem sprawę utrudnić. Np. wprowadzając w zespole zasady jakie biblioteki wolno wciągać a jakie nie.

OK. Zatem o co chodzi z tym N-Tier? Dlaczego BLL, DAL, warstwa prezentacji? Skąd ten podział, czy ma sens?

0 komentarze:

Prześlij komentarz

 
Tomasz Kulig