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

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

[Luneth]

Wow... nie spodziewałem się wznowienia tematu po takim czasie. Więc na początek tak:

@smentek - wybacz, że to powiem, ale Twój nick do Ciebie idealnie pasuje. To czepianie się jest smętne. Bardzo smętne. I w tym przypadku w 100% zgadzam się z Crozinem. Nic do tematu nie wniosłeś oprócz swojej jakiejś tam definicji, która - okej, może coś więcej tam uściśla, ale w gruncie rzeczy NIC do tematu nie wniosła konstruktywnego.

@dariuszp - nie wiedziałem, że tak skrajnie zabrzmiałem. Nie kusiło mnie nigdy pisanie funkcji i bibliotek dostarczanych wraz z PHP w myśl idealnego kopiowania ich działania. A co do dostępu modelu do kontrolera to możemy znowu się kłócić, że kontroler kojarzy model z widokiem a nie, że ma do niego dostęp. Bo w MVC kontroler jedynie te rzeczy ze sobą kojarzy. Sam fakt, że robienie obiektu ze zwykłej tablicy, żeby w niej trzymać same dane jest skrajny i posiada dużo wad - powiedzieli to już ludzie wypowiadający się na początku. Jak się zapewne domyślasz nigdy nie wprowadziłem tego pomysłu w życie. Chętnie poczytam o wzorcu data mapper, szczerze to jedyna informacja, która coś wnosi do tematu

Odwzorowanie źródeł danych w postaci obiektów daje ogromną zaletę. Programista który na tego typu mapperach operuje nie musi wiedzieć czy dane trafiają do bazy danych, pliku, zewnętrznego serwera czy na email jakiegoś trolla który potem będzie bluzgał że mu skrzynkę zaśmiecasz.

Zajeżdża trochę tym, czym jest po prostu model