Styl pisania kodu obiektowego korzystając z MVC, czyli do jakiego stopnia rozdrabniać moduły? Opcje

[Luneth]

Witam, załóżmy, że piszę sobie framework w MVC, wymyśliłem sobie, że zrobię moduł newsów w oparciu o ten wzorzec projektowy, np:

1. Kontroler rozszerza Widok, tworzy obiekt modelu, oraz korzystając z konstruktora rodzica przekazuje mu instancję tegoż modelu;
2. Kontroler wybiera jedną z dwóch metod: ShowSingleNews lub ShowNewsList, obie są metodami widoku - pobierają z modelu odpowiednio wybrane przez siebie dane, metodą widoku przekształcają timestampy na ludzkie daty, umieszczają element tablicy danych pobranych z MySQL do kodu html, wybierając jedną z trzech metod widoku: showPinned, showExtended, showOnList.
3. Wybrana przez kontroler metoda zwraca kod html jako string, który jest wyświetlany jako zawartość całej strony przez metodę widoku Display ( $this->ShowSingleNews() ) lub Display ( $this->ShowNewsList() )

Teraz przedstawienie problematyki: ogólnie filozofia programowania obiektowego opiera się na tym, aby obiekty traktować jako przedmioty, a atrybuty i metody jako ich własności i czynności, które mogą wykonać. Zgodnie z tym powinienem ponadto utworzyć sobie klasę NewsItem (i umieścić ją gdzieś osobno, bo nie wiem do czego miałbym ją przydzielić w MVC), miałaby ona atrybuty zgodne z polami w bazie danych a metody takie jak Show (czyli kod html - widok?), oraz gettery i settery. Ewentualnie można by pominąć to Show a zastosować właśnie same settery i gettery. Ale nowa klasa, nowy obiekt tylko po to, aby posiadał same settery i gettery jedynie po to, by w klasie News móc najpierw utworzyć pętlą tablicę obiektów, a następnie drugą pętlą wyświetlić zawartość obiektów? Poza ładną tablicą i faktycznym, abstrakcyjnym przedstawieniem struktury Newsów, tracimy na wydajności no i trochę w MVC sobie bałaganimy. Kończę swój wywód i czekam na Wasze odpowiedzi (IMG:style_emoticons/default/smile.gif)

Ten post edytował Luneth 9.08.2010, 00:44:50

[Zyx]

Jeśli mówimy o MVC, to tak. Model możemy opisać następująco:
- Interfejs jest niezależny od źródła danych
- Interfejs jest definiowany tak, by pasował do rodzaju reprezentowanych danych, czyli np. jeśli mamy newsy, wtedy będzie on pozwalał na tworzenie, edycję, usuwanie, komentowanie itd. Jeśli zaś ma reprezentować np. wirtualny system plików, wtedy posiada on funkcje do zarządzania tymi plikami.

Niedawno doszedłem do wniosku, że w typowej aplikacji znalazłoby się dużo rzeczy, które byłyby modelem, a nie znajdowałyby się w bazie danych. Weźmy np. menedżera nawigacji. W ZF masz do tego osobny, specjalistyczny komponent: Zend_Navigation. A przecież tak naprawdę jedyne, co on robi, to udostępnia pewne dane... widokom, czyli powinien być modelem.

Odnośnie drugiej części -> powtarzam: to, co piszesz, nazywa się ORM-em i są do tego gotowe biblioteki (np. Doctrine). Samodzielne pisanie to strata czasu. Pomysł z tworzeniem w pętli mnóstwa obiektów jest średnio ciekawy z powodów wydajnościowych. Jeśli nie potrzebujesz nic specjalnego w tych obiektach, lepiej jest zrzucić wszystko od razu do tablicy i posłać w świat. Obiektów PDO nie udostępniam poza modelem z powodu tego, co napisałem wcześniej: model powinien być niezależny od źródła danych, tj. powinien ukrywać fakt, że komunikuje się akurat z bazą.