Podział aplikacji - Modele,Services,Repozytoria Opcje

[Mr Albert]

Witam

Od dwóch lat tworzę aplikacje i strony internetowe. Jednak ostatnio spotykam coraz większe problemy z dzieleniem aplikacji.
Przy bardzo małych projektach zazwyczaj korzystam z Zend_Db_Table, idealnie sprawdza się to przy małych projektach, gdy nie trzeba za bardzo komplikować sobie życia podziałem na wiele warstw. Przy większych projektach korzystam z Doctrine ORM. Od początku nie tolerowałem upychania wszystkiego w kontrolerach, więc zazwyczaj korzystam z warstwy Services. Services zawierają w sobie większość logiki aplikacji, a doctrine używam głównie do zapisu i wczytywania danych z bazy. Services również korzystają z zewnętrznych źrodeł, gdy trzeba np api. W repozytoriach trzymam wszystkie zapytania dql oraz operacje na wielu entities. Dodatkowo repozytoria pełnią rolę transfer object w razie potrzeby. Zaimplementowałem w nich Iterator oraz Zend_Paginator_Adapter_Interface i gdy np. potrzebuje paginatora przekazuje odpowiednio wywołane repozytorium do widoku.

Ostatnio dużo czytałem na temat implementowania Modeli oraz tekstów dotyczących podziału aplikacji. Zauważylem, że tak naprawdę moje Services pełnią rolę Modeli, a doctrine robi za DAO. Ciągle jednak zastanawiam się czy np. Model_User pracować na wielu użytkownikach, jak powinna wyglądać prawidłowo warstwa Services, co powinny zawierać repozytoria. Ciekawi mnie jak wy dzielicie swoje aplikacje oraz czy korzystacie z ORM. Przy moim ostatnim projekcie przez korzystanie z doctrina czeka mnie spory refactor, bo pojawiło się wiele problemów przy niestandardowych rzeczach.

[LSM]

Nie wiem czy dobrze zrozumiałem Twój post. Ale jeśli nie to mnie popraw.
Zacznę skromnie bo zbytnie rozpisywanie się może pójść na marne.

Model można rozumieć tak:
http://www.wirfs-brock.com/PDFs/Determinin...Roles%20and.pdf
czyli jako po prostu coś co modelujesz i pojęcie bazy danych po prostu nie istnieje na tym poziomie rozumowania (choć w domyśle jest z tym że bazą danych może być dajmy na to zespół zmiennych konfigurujących klasę...)

Model można rozumieć też jako klasy dostępu do bazy danych jak to jest np. w CodeIgniter i wielu innych frameworkach.

Przyznam że miałem gwoździa w mózgu kiedy naczytałem się, wypraktykowałem i zdefiniowałem czym jest model i wnet ujrzałem CodeIgniter który nieco zburzył tą definicję - no bo jak to kurcze przecież tyle wiem a tu nagle twardziele od frameworka raczą mi powiedzieć że ich "model" to tylko klasy operujące na bazie danych ?

Czy o ten problem Ci mniej więcej chodzi ?