Witam,

No właśnie. W jaki sposób to wszystko połączyć tak, aby podczas przyszłej rozbudowy nie bluzgać na samego siebie?

Założenie jest takie, że korzystamy z jednego głównego pliku index.php, na którego kierujemy wszystkie requesty. On definiuje najpotrzebniejsze stałe (Ścieżka do aplikacji, środowisko itp.) a później pobiera główny plik z klasą (np bootstrap czy Kernel) i wywołuje w niej metodę Kernel::init()... i co teraz? Co mamy ładować pierwsze? Najpierw routing, sprawdzamy jaki kontroler mamy uruchomić. No dobrze, znaleźliśmy definicje kontrolera w konfiguracji i co teraz? Gdzie ją mamy wysłać? Do innej klasy, która teraz zajmie się uruchomieniem kontrolera użytkownika?

Zastanawiałem się nad podejściami dwoma:

1. Łańcuchowe. tzn.: Routing ma coś za zadanie, jeśli to zrobi to wywołuje coś, jeśli to coś co równiez ma swoje zadanie, jeśli zrobi to znowu wywołuje coś innego i tak dopóki nie dojdziemy do klasy zajmującej się wyrenderowaniem widoku.

2. Schodkowe, ale odpowiada za to jedna klasa. Np ta, która wywołamy na samym początku z pliku index.php. I ona pokolei pyta wszystkie klasy o coś, one jej zwracają a ona pyta dalej. Nie chodzi tu o pętlę ani nic w tym stylu. Wszystko napisane własnoręcznie więc podczas dodawania nowych fuknkcji wiadomo gdzie szukać.

Problem pierwszego rozwiązania jest taki, że podczas edycji czegoś, w określonych warunkach trzeba będzie zmieniać więle części aplikacji ponieważ jedna część wychodzi z wyniku poprzedniej.

Problem drugiego rozwiązania jest taki, że podczas rozrastania się aplikacji, metoda któa zajmuje się uruchamianiej każdej części aplikacji pobieraniem i zwracaniem danych bardzo się rozrośnie i może w niej pojawiać się mnóstwo błędów z tego względu.

Proszę o jakies propozycje lub uwagi do tego co napisałem. Wszystko mile widziane.

Jeśli masz czas i zapał, zapoznaj się dogłębnie z rozwiązaniami w istniejących frameworkach, najlepiej Zend i Symfony, już samo to dużo Ci naświetli, ale uprzedzam, nie jest prosto przez to przejść. No i musisz znać i rozumieć wzorce projektowe stojące za tymi rozwiązaniami. Jak się zagłębisz w dokumentację i studiowanie kodu, to sam sobie nakreślisz obraz możliwych rozwiązań i czemu tak a nie inaczej.

Przykładowo, w Zend Framework aplikacja inicjalizowana jest przez komponent Application, który następnie przekazuje sterowanie do front controllera, a ten odpala routing a następnie dispatching, który przekazuje sterowanie do kontrolera (tego z MVC).

Uważam, że jeśli nie umiesz sam odpowiedzieć sobie na postawione pytania i zaprojektować jak złożyć to w sensowną całość, to znaczy, że robienie tego to za wcześnie dla Ciebie.

@irmidjusz dobrze prawi. Szkoda, że nie ma tu opcji dodawania +1 do odpowiedzi, tak jak na stackoverflow.

Hmm, otóż wprowadziłem oba przypadki, które napisałem w pierwszym poście wprowadziłem do życia, ale żaden z nich nie wydaje mi się prawidłowy. Tzn. oba sprawdzają się na obecną chwile dobrze, ale wydaje mi się, że to nie jest dobre podejście.

Ja jestem jednym z tych ludzi, którym trzeba jednak czasami jakiś przykład postawić jasno przed oczami. Wiem, że idę na skróty może troszkę, ale nad Symfony siedział sztab ludzi - ja jestem sam. To tak, jakbym musiał ogarnąć encyklopedię, która nie jest posortowana alfabetycznie

Przeglądnę jeszcze raz kod Symfony.

@irmidjusz - Uważasz, że przekazywanie sterowania jest dobrym pomysłem? Z jednej strony problemem mogą być części aplikacji, które się ze sobą łączą. Może się zdarzyć tak, że jeśli zmienimy coś w jednym miejscu to możemy potrzebować zmiany w innym. Wiem, że dobrze przemyślana aplikacja to prawie w całości wykluczy, ale nie można tego skreślić.

Trinity - zobacz, Zyx pokazuje true MVC ;]

Trudne pytania zadajesz. Nie mam za bardzo czasu nad tym rozmyślać I co prawda kolega mnie pochwalił, ale nie czuję się zbytnio na siłach, by odpowiadać na takie pytania Więc proszę mnie nie wywoływać do tablicy
A odpowiadając, to tak, w pewnych rozsądnych granicach jak najbardziej. W ten sposób delegujesz wykonywanie zadań do komponentów (modułów, klas czy czego tam chcesz) odpowiedzialnych za konkretne rzeczy. To zdrowe, naturalne i potrzebne
A poza tym i tak pewien stopień zależności między głównymi (core) częściami aplikacji będzie istniał... ale: "Programuj za pomocą abstrakcji, nie implementacji" - czyli od Ciebie zależy, jak ściśle będziesz miał te komponenty powiązane.