Witam, ostatnio zacząłem nieco kombinować z obiektami w PHP i nasuwa mi się parę pytań o strukturę standardowej strony opartej na modułach. Zajmuję się php'em hobbystycznie, więc proszę o wyrozumiałość

Mam klase strona, w której umieściłem podstawowe metody jakie będę wykorzystywał (sprawdzanie modułów itd).
Następnie wewnątrz obiektu klasy strona tworze kilka innych obiektów jak np strona->db = db:singleton();
Całkowicie poza obiektem strona robie require modułów, każdy moduł będzie posiadał własną klasę "podstrona", jakieś filtrowanie danych $_GET, generowanie komunikatów itd...
I tutaj mam dylemat, jaką strukturę zastosować: czy lepiej będzie, jeśli klasa podstrona będzie rozszerzać klasę strona (będzie trochę bałagan) czy może lepiej robić jak do tej pory, czyli strona->podstrona = new podstrona; tylko, że wtedy znów będzie trochę kombinowania w przypadku gdy obiekt podstrona będzie potrzebował danych z obiektu strona...
Może jest jakiś inny, sensowniejszy sposób na to ?

dzięki z góry, pozdrawiam.

może to już czas na poznanie MVC ? na forum znajdziesz o tym dziesiątki tematów

co do modułów, gdy poznasz już wspomniany wzorzec projektowy to można rozwiązać to w ten sposób:

• każdy moduł ma osobny folder
• w każdym z nich można umieścić konfigurację, widoki, modele, kontrolery, klasy pomocnicze, biblioteki
• wszystko kategoriami wrzucasz do osobnych folderów
• pozostaje Ci do ustalenia kolejność warstw aplikacji, najczęściej spotykane: moduły -> aplikacja -> rdzeń.

przykładowa struktura folderów dla modułów:

jeżeli orientujesz się w obiektowym PHP nie powinieneś mieć problemu, zawsze możesz tutaj napisać

więc trzeba się zapoznać, thx

99% programistów PHP go nie zna. Wątpię też w to by ktoś, kto pyta o podstawy był w stanie go zrealizować poprawie (a niepoprawnie zrobiony MVC będzie chyba zawsze bardziej utrudniał życie niż ułatwiał).

Dlaczego ten obiekt jest singletonem? W czym przeszkadzałoby ewentualne współistnienie wielu obiektów tej klasy, reprezentujących różne bazy danych?

Do udostępniania "usług" (baza danych, logger itp.) lepiej wykorzystać bardziej sprawdzone metody, na przykład: dependency injection (tutaj akurat jako komponent symfony, ale możesz się po prostu więcej dowiedzieć o tym "czymś")

no cóż, co racja to racja.. ważne żeby nie brać przykładu ze złych implementacji i trzymać się podstawowych założeń wzorca (na początek poleciłbym ten art Zyx-a).

przeczytałem kilka artykułów i tutoriali, nawet one nie są spójne w kilku kwestiach


wiem, że będe uzywal jednej bazy, dodatkowo na czas tworzenia skryptu klasa db loguje zapytania, błędy i czas wykonywania.

po zapoznaniu się z tematem - idea MVC nie jest jakas skomplikowana, ale obawiam się, że zbyt dużo czasu zajmie komuś mało doświadczonemu w OOP samo przemyślenie i zaplanowanie wszystkiego. Do tego tworze aktualnie skrypt, z którego będę korzystał tylko ja, więc może coś wykorzystam z MVC, ale raczej nie będe się go sztywno trzymał.

dzięki za pomoc, pozdrawiam

możesz zapoznać się z jakimś frameworkiem i to byłoby najlepsze rozwiązanie w Twoim przypadku, na początek polecam Kohana w wersji 2.3.4, jest bardzo prosty i powinien wiele rzeczy rozjaśnić