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

[wookieb]

aby obiekty traktować jako przedmioty, a atrybuty i metody jako ich własności i czynności, które mogą wykonać.

To, że w definicjach jest napisane, że obiekty służa do lepszego opisywania rzeczywistości (a nie wszystko jest przedmiotem) wcale nie znaczy, że musisz ładować obiekty tam gdzie się da.
To, że samochód osobowy z definicji służy głównie do przewożenia osób to nie znaczy, że nie przewieziesz z tyłu 100kg kabaczek.

Nie ma sensu definiować obiektu dla każdego typu danych bo faktycznie wydajność spada a prawie nic dzięki temu nie zyskujemy więc nadal swobodnie można posługiwać się tablicami. Kontroler przekazuje je do widoku a widok robi z tym co chce.