[MVC][PHP]Jak to powinno wyglądać w MVC Opcje

[marekc12]

Hej,

dajmy na to, że mam 3 tabele w bazie:

tabela "tytuly": id -- tytul
tabela "tytul_gatunek": id -- tytul_id -- gatunek_id
tabela "gatunki": id -- gatunek

Jak widać druga tabela wiąże poszczególne rekordy z 1. i 2. tabeli ze sobą (relacja wiele do wielu).

Teraz chciałbym wyświetlić listę utworów i przy każdym wypisać do jakich gatunków należy.

Mogę to zrobić np. tak:

W modelu mogę stworzyć klasy dla tabel "tytuly" i "gatunki".

Widok poprosi klasę modelu "tytuly" o listę np. pierwszych 20 tytułów. Widok dostanie tę listę wraz z ich numerami id. Następnie widok poprosi klasę modelu "gatunki" (wysyłając jej numery id tytułów) o tablicę: z listą gatunków dla każdego id tytułu. Widok ją dostanie. Następnie wszystko poskłada i wyświetli.

Wydaje mi się to trochę zagmatwane za bardzo, bo jeśli bym to wszystko zrobił w jeden klasie modelu "tytuły" to zajmowałoby to mniej kodu.

pozdrawiam i z góry dzięki za wyjaśnienie problemu (IMG:style_emoticons/default/smile.gif)

Jak jest poprawnie zgodnie z modelem MVC, czyli jak powinno się to robić?

[Zyx]

lukaskolista -> to, co piszesz, to jedna z wielu późniejszych modyfikacji zwana "pasywnym widokiem", posiadająca swoją własną definicję i właściwości. Natomiast "MVC z pasywnym widokiem" != MVC. krzywy36, Crozin i inni dobrze mówią, a podane źródło to akurat jedno z lepiej opracowanych i uźródłowionych haseł w polskiej Wikipedii bazujące m.in. na oryginalnej definicji MVC oraz pracach naukowych i publikacjach specjalistów od inżynierii oprogramowania. Tylko w świecie części frameworków WWW przyjęło się nazywać piernik wiatrakiem, robiąc gigantyczny chaos.

Ponad to MVC to wzorzec, a z definicji slowa wzorzec wynika, ze nie jest to scisle okreslona regula, czyli kazdy kto mowi "To nie jest w MVC" niekoniecznie ma racje. Tutaj chodzi o rozwarstwienie aplikacji, a nie jakis sztywny schemat. Oczywiscie jak ktos wyswietla html w modelu czy kontrolerze to nie jest to zgodne ze wzorcem, tak samo jak pobieranie dancy w widoku i podobne anomalia.

Tak, to prawda, nie jest to ściśle określona reguła, a wzorce mają charakter ogólny i nie precyzują konkretnej implementacji. Za to posiadają pewne założenia, których modyfikacja może pociągnąć za sobą zmianę właściwości. Dlatego jeśli zmieniłeś założenia wzorca, stworzyłeś nowy wzorzec (lub antywzorzec (IMG:style_emoticons/default/smile.gif) ) o nowych właściwościach, a zatem nie powinieneś dla niego używać dotychczasowej nazwy. O tym już wielu programistów zapomina. Wzorce projektowe i architektoniczne to słownik: "jeśli architektura będzie zorganizowana tak i tak, to uzyskasz taki efekt", a tu mnóstwo programistów próbuje robić z niego burdel, powołując się na nadinterpretację pojęcia wzorca.