Małe pytanko odnośnie MVC, struktura folderów we frameworkach Opcje

[Forti]

Tak, wiem, pewnie ktoś zaraz wyskoczy, że odpowiedź znajde w google. Jednak przeszukiwałem i nie znalazłem.

Chodzi o proste pytanie. Przeglądam sobie artykuły o mvc, analizuje przykłady i teorie - wszędzie piszą, aby używać struktury folderów:
- model
- controller
- view

Wszystko fajnie pięknie. Jednak gdy zaglądam do frameworków (yi, CI itp.) na github, to ich struktura jest dla mnie jednym wielkim bałaganem, jeżeli chodzi o model - controller.

Znalazłem odpowiedź, że przy dużych projektach, struktura folderów model - controller - view jest trudna w utrzymaniu itp. Jednak konkretów brak. Może jest tu ktoś, kto potrafi to jasno wyjaśnić?

[Pyton_000]

Controller, View zostaw tak jak jest, a model przenieś np. tak:

/Acme
- Forms
- Validators
- Enities
- ....

[destroyerr]

Tutaj nie ma nic do wyjaśniania. Jeżeli dla Ciebie i dla autorów tych artykułów definicją architektury jest struktura folderów to jest to niepoważne. Jeżeli pytasz o wzorzec MVC to definiuje on tylko zadania poszczególnych warstw i kierunki komunikacji pomiędzy tymi warstwami. Pobieżnie rzuciłem okiem na CI i nie widzę tam bałaganu, więc postaraj się o konkretniejsze pytania.
Dziwną sprawą jest budowanie swojego doświadczenia z programowaniem obiektowym na podstawie CI.

[Turson]

Jednak gdy zaglądam do frameworków (yi, CI itp.) na github, to ich struktura jest dla mnie jednym wielkim bałaganem, jeżeli chodzi o model - controller.

Przecież Yii na strukturę:
-controllers
-models
-views

[Forti]

To ja jeszcze wielu rzeczy nie rozumiem z tego (IMG:style_emoticons/default/wink.gif) nie zawracam, ide dalej analizować kody i czytać teorie.

[Pyton_000]

Struktura to tylko pomoc w organizacji.

To tak jak z szafą na ubrania. Układasz jak Ci wygodnie a nie patrzysz na to kto jak robi. Są lepsze sposoby i gorsze. Eksperymentuj.

[Magan]

W moim frameworku to wygląda np. tak:

system/
class/ (kontroler - "main", dblayer, config_manager, sqlcache, userManage itd.)
(pozostałe)/
plugins/ (hooki)
templates/ (view)
php/ (model)
(inne)/

[gitbejbe]

@UP

fuuuuuu, ale brzydko (IMG:style_emoticons/default/nerdsmiley.png)

[Magan]

Fuuuuu, wersja wstępna, ale proszę bez offtopu. O gustach się nie dyskutuje, chciałem tylko potwierdzić zdanie przedmówcy odnośnie porównania struktury do szafy - tak jak wygodniej. Aczkolwiek mój framework jest tak skonstruowany, że zmiana struktury katalogów nie będzie wymagała dużo pracy, ot zmiany kilku inii kodu. Poza tym nie chodzi mi o to, by się chwalić, chodzi o to, by pokazać że może być tyle sposobów programowania ile osób interesuje się tą tematyką.

PS.: Mam również nadzieję, że nie miałeś zamiaru trolować, flamewar jest zbędny. (IMG:style_emoticons/default/wink.gif)

Ponadto obecna struktura fw jest uzasadniona tym, że rzeczywiście w "class/" znajdują się obiekt gdzie każdy poszczególny obiekt ma swoje zadanie, w tym kontroler scalający wszystko by funkcjonowało jak należy.

Ten post edytował Magan 19.09.2014, 13:13:55

[Turson]

model też jest klasą to czemu trzymasz w php/ a nie class/ ? A templates to raczej sugeruje layout a nie widok

[Magan]

W php trzymam wszystko pozostałe co nie potrzebuje być obiektem a było by napisane struktualnie (głównie pliki includowane przez obiekt modelu w zależności od wyświetlanej strony, tak samo jak robi to obiekt widoku wywołujący poszczególne tpl-ki). Trzymanie się obiektowego programowania w zdecydowanej całości jest wg. mnie w negatywnym kontekście skrajnością. Jeśli się głębiej zastanowić to na upartego można również stwierdzić że metody obiektu to niekiedy formy struktualne, a nie stricte obiektowe.

Ten post edytował Magan 19.09.2014, 13:17:49

[Turson]

Więc na jakiej zasadzie ładujesz model do konkretnego kontrolera, skoro nie pobierasz instancji klasy? Samo include? I co wtedy jak chcesz z pewnego kontrolera odwołać sie do innego modelu, znowu include? Polecam najpierw popracować trochę na jakimś porządniejszym fw, żebyś wyrobił sobie kilka zdań na tego, jak co powinno mniej więcej wyglądać (IMG:style_emoticons/default/wink.gif)

[Magan]

Dziękuję uprzejmie za radę aczkolwiek chcę najpierw trochę poeksperymentować. To czy mój pomysł okaże się wydajny i lekki, okaże się po czasie gdyż chcę postawić na nim m.in. swój blog i przenieść grę (w js/html5/php). Pokrótce zrobiłem to tak, że każdą klasę wywołuję poprzez kontroler, zaletą jest m.in. to, że mogę hookować wszystko co nie znajduje się na czarnej liście czyli spore możliwości modowania silnika bez ingerencji w sam silnik. Innymi słowy, ogólnie, wszystko zależy jakie są założenia projektu, taka powinna być struktura.

A, i nie samym include silnik żyje a tym, że tworzy instancje obiektów do własnej zmiennej (tablicy) i wszystko jest wywoływane przez __call().

Ten post edytował Magan 19.09.2014, 13:29:46