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

[dariuszp]

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 smile.gif

Mieszasz wg mnie za bardzo. NewsItem powinien być elementem kontrolera. Ten powinien mieć dostęp do modelu przez jakiś interfejs (najczęściej za model robi baza danych). Świetnym wzorcem który przypadł mi do gustu jest Data Mapper. Poczytaj. 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.
Odpowiednio przygotowane dane (przygotować je może jakiś adapter bądź sama klasa NewsItem) powinny trafić do widoku. Widok ma się nimi zaopiekować i w odpowiednim miejscu wyświetlić.
To czy będziesz operował na danych tablicowych czy obiektach to już kwestia wyznania. Podejście gdzie WSZYSTKO jest obiektem w PHP wg mnie jest cokolwiek chore. Dane powinny płynąć z jednego miejsca do drugiego w postaci tablic, ciągów znaków i obiektów w zależności od potrzeb i możliwości. Na pewno nie generował bym 200 obiektów tylko po to by tak pobrane dane iterować i umieszczać w szablonie.

Kod

dokładnie tak samo myślę, chociaż kusi mnie taka dokładna obiektowość, może dlatego, że jestem trochę pedantyczny w takich sprawach

Wiesz, mnie kusi by czasami przywalić komuś w gębę. Wykonanie tej czynności na pewno sprawiło by mi przyjemność ale skutki mogły by być różne. Sam widziałem absurd obiektowości u gościa który nawet ciągi znaków zamykał w obiektach (stworzył sobie klasę string z użyciem invoke(), toString() i innymi metodami magicznymi które są dla nas dostępne (invoke() chyba od php5.3). Jak to profilowałem to złapałem się za głowę.

Kod

Model ma być niezależny, bo przewidujemy różnorodność źródeł danych i ich format (różne bazy danych, pliki, etc) ? Swoją drogą nie miałem zamiaru zastępować modelu taką klasa Newsa, u mnie miałoby to działać tak: Dane z modelu -> (pętla tworząca tablicę obiektów)NewsItem ->  (pętla tworząca kod html tejże listy używając obiektów NewsItem)NewsList -> RenderPage()

Jak mówiłem. Skoro przewidujesz różne źródła danych to zmappuj je. Troszkę się opiszesz przy mapperach ale potem pójdzie gładko. Właściwie przy bazie danych szybko załatwisz sprawę. Po zbudowaniu mappera, rozszerzając go podasz tylko specyficzne pola dla tabel + nadasz jakieś filtry i tyle. Potem tylko:

$news_item->save($mapper);
$news_item2->save($mapper);
$news_item3 = $mapper->load_by_id($id);
$news_item3->delete($mapper);

Użytkownik Twojego kodu nawet nie musi mieć pojęcia co się stało z danymi po zapisaniu i gdzie one są.

Kod

Obiekt nie musi być fizycznym bytem jak było to sugerowane wcześniej.

Hmmm... ciekawość :-) Jakie nie-fizyczny byt proponował byś ?

Pozadrawiam.

Luneth, a co do pytania w temacie:
Jak rozdrabniać moduły ? NIE ROZDRABNIAĆ ICH O ile obiekt odpowiedzialny za obsługę bazy danych, plików czy czegokolwiek innego "od środka" powinien mieć ziarnisty interfejs (dużo metod od różnych akcji) o tyle sam interfejs obiektu czyli to co jest dostępne użytkownikowi Twojego kodu (i Tobie) powinien być ograniczony do minimum. Samo zaś traktowanie wszystkiego jako obiekt jest moim zdaniem błędne. Jeżeli potrzebny Ci do czegoś obiekt to go utwórz. Ale nie ma sensu np pobrać dane np z bazy, upakować je w 200 obiektów a następnie wyświetlić. O wiele lepiej jest przekazać tablicę. Chyba że masz jeszcze coś skomplikowanego robić na każdym z tych 200 rekordów bazy.