MVC, gdzie trzymac informacje o jaki widok ma mieć dana strona Opcje

[nowy_pehapowiec]

Czy nazwę widoku trzymać w bazie danych, czy w gdzieś w kodzie php? Jak lepiej?

pozdro

[thek]

Jak dla mnie wiedzę o widoku realizuj tak, jak wiele spośród frameworków. Zrzuć to na karb kontrolera

[nowy_pehapowiec]

Dzięki!
A powiedz mi jeszcze co poza routerem, definicją połączenia z bazą, definicjami stałych i wywołaniem kontrolera ma być w index.php ?

[quality]

To zalezy od tego jaka masz aplikacje.

Najprosciej tlumaczyc to wlaczanie wylaczanie, jakis glownych komponentow, obsluga pluginow. Rozne rzeczy mozna umieszczac Obsluga sesji itp. ogolnie glowne rzeczy ktorych bedziesz uzywal i potrzebowal w calej aplikacji, nie ma dokladnie okreslonych zasad co ma byc a co nie.

[nowy_pehapowiec]

Ok, czyli model i widok wywołuje już w kontrolerze tak?

[Prph]

Ile frameworków, tyle pomysłów.

Generalna zasada: model to dane, widok prezentuje te dane, a kontroler tym wszystkim steruje. Kontroler może pobierać dane z modelu i przekazywać do widoku, ale równie dobrze widok sam może je pobierać i wyświetlać. Istotne jest, żeby model faktycznie w tym uczestniczył. Ani kontroler, ani widok nie operuje bezpośrednio na bazie danych (SQL).

Kontroler to dobre miejsce na nazwę widoku. Zdarza się, że kontroler wybiera różne widoki na podstawie danych (jeżeli formularz zawiera poprawne dane, wyświetl informacje o powodzeniu, w przeciwnym razie stronę z informacją o niepowodzeniu).

Widoki, bazy i inne rzeczy możesz konfigurować w index.php. Gdzieś w końcu trzeba.

Polecam przejrzeć dostępne frameworki i popatrzeć, jak zrobili to profesjonaliści.

[Crozin]

Czy nazwę widoku trzymać w bazie danych, czy w gdzieś w kodzie php? Jak lepiej?

Ogólnie zadaniem kontrolera jest określenie, że ten a ten widok, ma wyświetlić dane z tego, a tego kontrolera.

@quality: Takie rzeczy jak sesja to zadanie stricte dla modelu.

Generalna zasada: model to dane, widok prezentuje te dane, a kontroler tym wszystkim steruje.

To co opisałeś to nie jest idea wzorca MVC.

Polecam przejrzeć dostępne frameworki i popatrzeć, jak zrobili to profesjonaliści.

W większości przypadków... źle.

[Prph]

To co opisałeś to nie jest idea wzorca MVC.
W większości przypadków... źle.

No tak, idealista Spotkałem się z wieloma implementacjami MVC - w PHP i w Javie. Początkowo jak spojrzałem na Zend Framework, pomyślałem, że chłopaki trochę naginają. Po 2 latach programowania w ZF stwierdzam, że architektura w tym frameworku jest wręcz rewelacyjna.

Czasem nie da się idealnie przenieść teorii wzorca projektowego na prawdziwy, działający system. Przecież w tym wszystkim chodzi o to, żeby było łatwiej tworzyć oprogramowanie. Łatwiej != superpoprawnie.

[Crozin]

W żadnym wypadku to co napisałem nie jest "idealistycznym zboczeniem". Sam korzystam z FW Symfony, który ma niby implementować ów wzorzec (czy chociaż jego główne idee), ale jak większość... tego nie robi (wersja 2 dosyć znacząco poprawiła sytuację). Nie zmienia to faktu, że bardzo dobrze mi się z niego korzysta - jednak: mogło by być lepiej. Większości popularnych FW PHP bliżej do implementacji MVP niż MVC (gdzie na dobrą sprawę dużą część V, przejmuje C).

btw: Wzorce to sprawdzone rozwiązania popularnych problemów - i dobrze wiem, że nie zawsze robi się tak jak to one określają, bo nie zawsze jest to korzystne. Ale jeżeli robimy coś innego (co może być czymś lepszym) to nie nazywajmy tego nazwą czegoś innego.