Chciałym aby wszyscy podzielili się własnymi rozwiązaniami, czyli w jaki sposób budujecie swoją aplikacje?
Wiadomo każdy pisze jak mu najwygodniej, i nie ma idealnego rozwiązania dla wszystkich. Dlatego ten temat ma na celu porównanie waszch rozwiązań.

1. Jak rozmieszczanie foldery klasy, funkcje itp?
2. Używacie gotowych wzorców ?
3. Stosujecie OOP, MVC czy raczej strukturalnie?



Temat jest rozszerzeniem tego tematu: Temat: php Akcje Kontrolery Pluginy Moduly.

Jeśli chodzi o mnie to:
dir _Actions
Surowy podział klas do zarządzania jakimiś elementami (Data i czas; Upload plików; Obrazki - formatowanie, zmniejszanie; handler MySql itp.. itd..)

dir _Controller
Rozpoznaje żadanie, odwołuje się do odpowiedniego modułu wywołując żądanie. Pobiera wynik i ubiera go w html. Na koniec zwraca wynik do przeglądarki

dir _Modules
Jak sama nazwa wskazuje Moduły, czyli operacje na bazach danych wykorzystanie Pluginów i Actions, zwracanie wyników itp.

dir _Plugins
Klasy wykorzystujące _Actions np połaczenie Uploadu plików i formatowania obrazków. co w połączeniu daje nam Uploader obrazków który będzie pomniejszał i formatował obrazki lub Sesion Handler (korzystający z _actions/mysql itd..

dir _Template
katalog z plikami .tpl

Nie używam gotowych wzorców, zawsze piszę własne. OOP i MVC (po swojemu OfCourse )
Dodam jeszcze że piszę dość sztywno. Tzn to co jest PLuginem jest pluginem i nie korzysta z innego pluginu... ktory jeszcze korzysta z jakiegos pluginu (błedne koło). Plugin korzysta jedynie z Actions (które już nie korzystaj z podklas).
Chodzi mi o surowy podział i porządek. Tak mi jest najwygodniej i łatwiej sie polapac.

U mnie podział katalogów/plików jest nieco narzucony przez kontrolę wersji (subversion) ale nie to, żeby to było jakimś minusem czy ograniczeniem, wręcz jestem wdzięczny za wymuszenie tego podziału:

• __global
  Pliki globalne frameworku czyli pliki nie zależne od konkretnego projektu, po prostu algorytm stanowiący o działaniu frameworka jak i dodatkowe funkcje czy komponenty, które mogą być wykorzystane w różnych projektach zależnie od jego potrzeb, w tym katalogu też trzymam globalny plik konfiguracyjny jedyny plik konfiguracyjny i jedyny, który nie jest wersjonowany przez kontrolę wersji, zawiera on przede wszystkim definicje stałych, których wartości są uzależnione od środowiska w którym projekt działa.
  • _components
    Zewnętrzne komponenty, które są wykorzystywane w aplikacjach, przykładowo komponent do obsługi bazy danych, komponent walidujący żądania użytkownika (np. dane z tablic GET i POST czy też adresy url, jeśli korzystamy z przyjaznych url'ów), komponent mail.. podsumowując są kompenenty zbudowane na kształt tych jakie są w Zend Framework czy eZcomponents (mogą to być faktycznie komponenty wzięte z tych projektów)
  • htdocs
    Katalog ten zawiera podkatalogi takie jak _css, _js, _img. Pliki (teoretycznie) statyczne, które są przydatne nie zależnie od charakteru projektu.. przykładowo funkcje javascript uzupełniające brakującą funkcjonalnośc w IE, obrazki pół przezroczyste (na przykład czarny z opacity 50%), czy arkusz styli resetujący domyślne style przeglądarki, które bardziej przeszkadzają niż pomagają w projektowaniu
  • includes
    Główne pliki frameworku takie jak header.inc.php (always prepended file), footer.inc.php (always appended file), functions_core.inc.php, pliki które są wczytywane w momencie odpalenia i ogólnie spinają cały framework. Tutaj są zdefinowane funkcje za pomocą których elementy frameworku się komunikują. Poza tym trzymam tu klasy uzupełniające podstawową bibliotekę php. Przykładowo klasa str, ze statycznymi metodami operującymi na stringach, są tu też w podkatalogach _css i _js klasy czy pliki pomocne w dynamicznym budowaniu arkuszy styli czy skryptów js
  • other
    W __global'u ten katalog ma nie wielkie zastowanie, ogólna idea jest by trzymać tu informacje ściśle związane framewrokiem, jednak nie biorące udziału w jego pracy. W tej chwili jest tu tylko przykładowy plik globalnego konfigu, który pokazuje jakie stałe powinny być zdefiniowane w tym pliku konfiguracyjnym.
• Przykładowy projekt
  Po prostu projekt osadzony na frameworku, w tym katalogu znajdują się pliki projektu, nie ma tu żadnych plików o charakterze uniwersalnym, które mogłyby być przydatne również w innych projektach.
  • htdocs
    Kontrolery aplikacji jaki statyczne pliki typu arkusze styli, skrypty js, grafiki. Front controllerem jest sam apache i jakby on decyduje, do którego kontrolera następuje odwołanie (Do tego katalogu prowadzi DocumentRoot w konfiguracji apache'a) Gdy w danym środowisku nie mamy dostępu do konfiguracji apache'a można w tym katalogu umieścić front controller (index.php), który poprzez php będzie ładował odpowiednie kontrolery.
  • modules
    Źródło projektu
    • _controller
      Klasy kontrolera. Tak naprawdę istnienie tych klas jest uzależnione od tego jak dużo pracy ma kontroler w naszej aplikacji lub też czy rozdzielone kontrolery w htdocs nie korzystają z powtarzających się algorytmów. Może być tak, że podstawa funkcjonalność zawarta w plikach w katalogu htdocs jest zupełnie wystarczająca i nie ma potrzeby na budowanie dodatkowych czy też bardziej uniwersalnych modułów.
    • _model
      Model danych. Wewnętrzna logika aplikacji w tym warstwa wymieniająca dane pomiędzy bazą i aplikacją (w podkatalogu _dao)
    • _view
      Interejs użytkownika, jest to miejsce, w które można ładować pliki tpl (lub ewentualnie z którego można wywoływać pliki tpl umieszczone w jakimś zewnętrznym katalogu). U mnie jednak jest to nieco inaczej rozwiązane, buduję interfejs modułowo wykorzystując możliwości obiektowego programowania. Tak więc są to klasy (nie szablony) widoku. Nie korzystam ze Smarty ani też nie wpisuje html'a bezpośrednio w php, ogólnie to byłby temat na inny wątek jak to się odbywa. Buduję dokument jako drzewo DOM wykorzystując dedykowane rozszerzenie php z wykorzystaniem dodatkowych klas, które usprawniają cały proces.
      Oczywiście framework w żaden sposób nie narzuca korzystania z takiego rozwiązania.. gdybym chciał mógłbym zaprzągnąć Smarty i bazować na szablonach.
  • other
    Pliki nie biorące udziału w pracy aplikacji ale zawierające dane ściśle z nią związane, pliki które też powinny być pod kontrolą wersji. Przykładowo struktura bazy danych w pliku SQL

Tak to mniej więcej wygląda u mnie, też nie korzystam z żadnych gotowych frameworków nie mniej staram się je podglądać i zrozumieć jak to jest u nich rozwiązane (choć niestety rzadko się zdarza by było to łatwe )..
w tym momencie jestem w trakcie budowy parę projektów z wykorzystaniem powyższego modelu i jak na razie jestem bardzo zadowolony z tego jak to się rozwija.. zobaczymy jak będzie dalej