Warstwowa budowa aplikacji - gdzie włożyć konkretne funkcje?

Odpowiedz Nowy wątek
2011-10-11 14:14
0

Mam warstwową budowę systemu do obsługi biura turystycznego.
Warstwy czytać od dołu:

-Prezentacja
-Business Objects / Services
-DAO
-Obiekty modelu (Wycieczka, Rezerwacja, Hotel itp)
-Baza danych

Nie jestem pewny czy takie rzeczy jak:
a) obliczanie liczby wolnych miejsc w wycieczce,
b) obliczanie całkowitej liczby miejsc w wycieczce,
c) proste wyszukiwanie wycieczki na podstawie dat i miejsca pobytu
powinny się znaleźć w warstwie DAO czy raczej BO?
Używam tam obiektów modelu, "kłerowania" przy pomocy DetachedCriteria więc raczej obstawiam DAO, słusznie?

edytowany 1x, ostatnio: Lancer, 2011-10-11 14:14

Pozostało 580 znaków

2011-10-12 11:16
LEM
0

To o czym mówisz, zależy od tego na jakim wzorcu aplikacyjnym zorganizowana jest warstwa logiki biznesowej. Jeśli masz Domain Model to wszelka logika winna być wykonywana w obiektach biznesowych. Wzorzec Active Record - wtedy w warstwie usługowej (fasadzie). Podobnie dla wzorca Table Module. DAO/Repozytoria nie powinny realizować logiki biznesowej.

Pozostało 580 znaków

2011-10-13 13:13
0

W moim przypadku najbliżej będzie do Domain Model.

Wiem, że "DAO nie powinny realizować logiki biznesowej". Co ma więc obejmować ten interfejs dostępu do danych? Czy mają to być jedynie operacje typu load, save, delete?
Czy może to być jeszcze w moim przypadku np. findTourByPlace (znajdź wycieczkę na podstawie miejsca wycieczki)? Czy to już jest może "logika biznesowa"? Bo rozumiem że Twoim zdaniem takie obliczanie wolnych miejsc wycieczki to już logika biznesowa, tak?

edytowany 1x, ostatnio: Lancer, 2011-10-13 14:39

Pozostało 580 znaków

2011-10-13 16:15
0
Lancer napisał(a)

Co ma więc obejmować ten interfejs dostępu do danych? Czy mają to być jedynie operacje typu load, save, delete?

Tak, DAO musi umieć tylko przetwarzać obiekty Modelu na kolumny bazy danych i z powrotem. Nic więcej, przynajmniej dopóki nie zajdzie potrzeba optymalizacji. Metody na wejściu przyjmują obiekt i zapisują go do bazy, albo np. zwracają listę obiektów Modelu wczytanych z bazy.

Czy może to być jeszcze w moim przypadku np. findTourByPlace (znajdź wycieczkę na podstawie miejsca wycieczki)? Czy to już jest może "logika biznesowa"?

Moim zdaniem to też DAO - w końcu to pobieranie z bazy obiektu.

Bo rozumiem że Twoim zdaniem takie obliczanie wolnych miejsc wycieczki to już logika biznesowa, tak?

Jak najbardziej, podczas kupowania wycieczki przez klienta, jedną z operacji powinno być zmniejszenie licznika wolnych miejsc, czyli jednej z właściwości obiektu Wycieczka, który potem zostanie zapisany do bazy.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Optymalizacja kosztem zaburzenia budowy warstwowej? To się może odbić czkawką. - ElevenEleven 2011-10-18 19:21
Niekoniecznie zaburzenia - np. widok służący do wyciągania jakiejś bardziej skomplikowanej struktury danych można stworzyć w bazie, a potem wywoływać go z aplikacji "warstwowo" mapując do oddzielnej klasy, itd. A czegoś takiego, jak wyznaczanie numeru faktury, chyba nie da się zrobić inaczej niż przez bazę. - somekind 2011-10-18 20:17

Pozostało 580 znaków

2011-10-14 12:09
LEM
0

W przypadku Domain Model

Czy może to być jeszcze w moim przypadku np. findTourByPlace (znajdź wycieczkę na podstawie miejsca wycieczki)? Czy to już jest może "logika biznesowa"?

Moim zdaniem jest to logika, która powinna znaleźć się w jakimś biznesowym obiekcie agregującym - np "katalog wycieczek".

Domain model jest stosowany do rozbudowanej logiki biznesowej, zapewnia wysoka elastyczność i hermetyczność, ale tez sporo nadmiarowego kodu w stosunku do prostszych wzorców architektury.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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