Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Podział aplikacji - Modele,Services,Repozytoria
Forum PHP.pl > Forum > PHP > Object-oriented programming
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 ?
Mr Albert
Staram się unikać rozumienia Modeli tak jak to jest właśnie w popularnych frameworkach. Głównie chciałem się dowiedzieć jak wyglądają u was Modele oraz gdzie umieszczacie metody np do obsługi wielu użytkowników , czy w modelu czy jeszcze gdzieś ińdziej.
destroyerr
Polecam zainteresować się Domain Driven Design, nawet jeśli nie zawsze jest sens stosować się do wszystkich zaleceń, to i tak warto skorzystać z niektórych. Z opisu wynika, że Twój model zmierza ku Building Blocks.

Co do obsługi na wielu użytkowników, to zależy co masz namyśli. Jeśli jakieś operacje (zmiana stanu tych użytkowników) to powinno być to w serwisie/usłudze domeny (nie aplikacji). Natomiast jeśli chodzi tylko o wyświetalanie to tutaj będzie różnie, jedni będą radzić pobieranie encji z repozytorium, inni obiektów transferowych albo dodanie kolejnej warstwy do raportów (patrz CQRS).
Mr Albert
A może macie jakiś konkretne przykłady wraz z kodem najlepszych wg was implementacji ?
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.