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.