Warstwa modelu we wzorcu MVC Opcje

[Martio]

Przeglądałem dzisiaj kilka najpopularniejszych frameworków w PHP i zauważyłem, że w większości przypadków model składa się z warstwy dostępu do danych. I tak "Zend Framework" oferuje bramę danych w bibliotece "Zend_Db_Table", zaś "Symfony" używa "Propel" jako ORM.

I gdzie teraz tutaj jest miejsce na logikę biznesową jak np. zadanie obliczenia przychodu? I czy kompletnie zrezygnowano z warstwy usług ("service layer") ? Z tego co wywnioskowałem to w takich przypadkach do kontroli transakcji i koordynowania odpowiedzi służy akcja w kontrolerze akcji. Pomimo, że RoR nie jest PHP-owym frameworkiem, to tam występuje podobna sytuacja.

Czy tylko frameworki Javy stosują w pełni prawidła warstwy modelu we wzorcu MVC dzieląc go na warstwę logiki biznesowej, warstwę dostępu do danych i pośredniczącą pomiędzy logiką, a aplikacją warstwę usług?

Czy macie może jakieś przykłady jak zastosować logikę biznesową i ew. warstwę usług np. w Zend Framework czy Symfony?

Proszę o pomoc i dyskusję.

[Cysiaczek]

Wydaje mi się, że po prostu trzeba do wdrożyć samemu. Jak wspomniałeś, to akcja jest głównie odpowiedzialna za logikę biznesową we frameworkach php. To, jak bardzo ją sobie skomplikujesz, zależy od Ciebie. W Symfony (najbardziej zaawansowany FW dla php) domyślnie do akcji upychany jest DAO, który leci potem do widoku. Nie widzę problemu, aby dopisać do tego model dziedziny użyć w ciele akcji zamiast DAO. W javie może wygląda to inaczej, ale w php frameworki są pisane po to, aby wspomóc pisanie aplkacji www, które rządzą się innymi prawami niż okienkowe. Zazwyczaj cała warstwa usług sprowadza się tu do wykonania rollback na bazie danych, lub usunięciu utworzonego pliku, jeśli coś w którymś momencie poszło nie tak. Wiele więcej nie zdziałasz, bo za chwilę połączenie zostanie zakończone i do czasu następnego, aplikacja nie istnieje.
Bolesna prawda jest taka, że samo DAO wystarcza w 80% przypadków. Reszta pierdół ląduje goła, w ciele akcji.

Pozdrawiam.

[Sedziwoj]

Nie jestem pewien czy dobrze zrozumiałem (za dużo ostatnio mam na głowie), ale nie chodzi o wykorzystanie klasy która jest generowane przez Propel i jest domyślnie pusta. Tam możemy umieszczać wszystkie działania związane z danym danego obiektu.
Ja to wykorzystuję np. kiedy do danych rekordów przypisane są pliki i jak ktoś wywoła usunięcie informacji o ścieżce do pliku lub usunie krotkę, to niewidocznie dla nikogo usuwa też pliki które są już zbędne, czy typowe pobieranie jakiś list gdzie samo tworzenie Criteria do tego i innych rzeczy zajmuje sporo linii. Czyli to jest miejsce na taki pośrednik między samym ORM a akcjami go wykorzystującymi, gdzie mogą być jawne metody lub nadpisane standardowe.
Jak się to wykorzystuje to nie trzeba pilnować za każdym razem pewnych rzeczy, tylko zrobi za nas właśnie kod umieszczony w tych klasach. Gdzie wiemy że coś jest robione, wiem co ale nie wiemy gdzie (bo to nas tak na prawdę nie obchodzi).

(ciekawe czy dobrze zrozumiałem problem... bo mam obawy że nie)

[Cysiaczek]

Tu chyba raczej chodzi o warstwę, która zarządza logiką biznesową (jesczcze wyżej niż akcja i model).
Obejmuje ona np. transakcje biznesowe z wieloma podakcjami, które muszą zostać wykonane prawidłowo
np.

1. Zweryfikuj klienta
2. Przygotuj wypłatę
3. Przelej pieniądze

To się da zrobić posiadając zaawansowany system łańcuchów akcji. Nie chwaląc się, to ja taki mam w FW ;p
Zazwyczaj jednak przygotowuje się oddzielną warstwę.

[Martio]

Dokładnie o to chodzi. A możesz zademonstrować taki przykład tej warstwy? Warstwy, która jest pomiędzy akcją, a DAO i w której jest wykonywana transakcja biznesowa.