[skrypt] MVC podstawowy silnik + przykładowe klasy |
[skrypt] MVC podstawowy silnik + przykładowe klasy |
18.05.2011, 15:50:53
Post
#1
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
napisałem takiego oto potworka, z założenia jest to projekt szkoleniowy, który rozwija się w miarę przyswajania nowej wiedzy, składa się z kilku elementów
proszę o krytykę, mam wrażenie, że trochę błądzę w założeniach MVC i chcę mieć pewność w których miejscach proszę tylko nie do końca zwracać uwagę na "niefortunnie" dobrane nazwy klas i funkcji, wiem, że wymaga to staranniejszej organizacji, na razie jest tak, by __autoload łapał wszystkie potrzebne mi klasy o dziwo potworek ten działa tak jak zakładałem .htacces przekierowuje wszystko na index.php a linki buduję np. tak www.mojastrona.pl/product/viewproduct/25 index.php - załącza ini.php, tworzy router, tworzy dispatcher, przekazuje router do dispatchera
ini.php - ustala ścieżki i załącza funkcję __autoload
cConfigs.php - udostępnia dane
cRouter.php - obsługa adresu wywołania (dzieli url na parametry)
cDispatcher.php - pobiera dane z routera i przetwarza je (sprawdza czy są poprawne i dozwolone, zwraca wartości domyślne - inicjuje właściwe kontrolery i akcje)
cController.php - kontroler rodzic, ustawia parametry dla akcji, sprawdza ich ilość, ustawia model i widok
cInterfaceBasic.php - żąda funkcji index() która jest domyślną dla wszystkich kontrolerów
cProducts.php- kontroler produktów - domyślny kontroler - wywołuje akcję index() która listuje wszystkie produkty lub akcję viewproduct pokazującą pojedyńczy produkt po parametrze $id produktu
cErrornopage.php - klasa błędu - tylko na potrzeby zaznaczenia momentu błedu
cDB.php - baza danych
cModel.php - model
cView.php - klasa widok - rodzic
CViewProducts.php - widok dla listy produktów
cViewViewproducts.php - widok dla pojedynczego produktu
baza danych zapożyczona z innego przykładu
Ten post edytował olechafm 18.05.2011, 15:50:30 |
|
|
18.05.2011, 15:55:04
Post
#2
|
|
Grupa: Moderatorzy Postów: 4 069 Pomógł: 497 Dołączył: 11.05.2007 Skąd: Warszawa |
getParametry()
zamiast: set_include_path(get_include_path().PATH_SEPARATOR."core"); set_include_path(get_include_path().PATH_SEPARATOR."core/main"); daj: set_include_path('.' . PATH_SEPARATOR . 'core' . PATH_SEPARATOR . 'main/main' ); |
|
|
20.05.2011, 14:54:16
Post
#3
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
to jest akurat na żywca z książki (Programowanie Obiektowe w PHP5 autorstwa Hasina Haydera oczywiście, jakby ktoś chciał się pośmiać ) , cala funkcja __autoloda będzie inaczej napisana (się pisze właśnie) jak tylko ustalę sam ze sobą strukturę katalogów i nazewnictwo plików, i będzie miała jasno określone ścieżki bez tych elementów
set_include_path(get_include_path().PATH_SEPARATOR."core"); up |
|
|
20.05.2011, 18:10:20
Post
#4
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
Nie musisz ustalać sam ze sobą nazewnictwa klas, katalogów i plików, bo po co komu "n+1szy standard nazewnictwa, który nie jest z niczym kompatybilny"? Poczytaj sobie o PSR-0, zobacz na zasady nazewnictwa w Symfony 2 / Zend Framework 2 i użyj jednej z gotowych ładowarek klas dla tego standardu. Unikniesz mnóstwa niepotrzebnych problemów, a jak Ci coś fajnego wyjdzie, będziesz mógł tego z marszu używać w połączeniu z normalnymi platformami bez konieczności przepisywania kodu.
Jeśli chodzi o koncepcję i zgodność z założeniami wzorca, to zasadniczo jest OK. Oczywiście od strony rozszerzalności czy konfigurowalności masz sporo rzeczy zakodowanych na sztywno, ale to już jest cecha konkretnej implementacji, a nie zgodności ze wzorcem. Tu szczególnie przyczepię się do jednego: Kod <?php class model extends DB Hehe, od kiedy to model jest odpowiedzialny za komunikację z bazą danych? Nie bez powodu mówi się, że mechanizm dziedziczenia pozwala na tworzenie bardziej wyspecjalizowanych klas. Specjalizacja = dostosowanie bardziej ogólnej funkcjonalności do bardziej szczegółowego przypadku, a nie dodanie nowej funkcjonalności. Czy pobranie produktów jest jedną z operacji służących do komunikacji z bazą danych? Nie. Ono z tej komunikacji jedynie korzysta, czyli nie używamy dziedziczenia. -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
26.05.2011, 09:30:50
Post
#5
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
Dzięki za odpowiedź, to była jedna z rzeczy których nie byłem pewien. A co do PSR-0 (może ktoś ma link do jakiegoś dobrego przykładu albo po ludzku napisanej dokumentacji?) to tak, oczywiście wiem, że istnieje i chętnie zacznę go używać jak tylko go dostatecznie zrozumiem, tak jak napisałem już wcześniej nie da się wszystkiego od razu robić dobrze, na początku zbyt wiele jest do nauki...
|
|
|
26.05.2011, 09:55:23
Post
#6
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
To jest zwykły standard nazewnictwa i tam nie ma nic do rozumienia. Po prostu nazywasz klasy tak, jak jest podane i to wszystko.
-------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
26.05.2011, 14:06:14
Post
#7
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
Oj jest, może wydaje się, że to oczywistości są, ale gdy wcześniej nauczyło się złych rzeczy to przestawić się później trudno, szczególnie, że jak i we wszystkich innych przypadkach, ciężko o napisaną po ludzku wersję angielskiej dokumentacji czy przykład pokazujący chociażby kilka klas itd...
|
|
|
26.05.2011, 14:32:46
Post
#8
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
Jak sobie klikniesz w jeden z dwóch linków widocznych w mojej stopce, będziesz mieć nawet dwa przykłady pokazujące kilka klas i zgodne z tym nazewnictwem .
-------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
27.05.2011, 11:34:41
Post
#9
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
niema to jak autopromocja tak wiem, że one tam są i przedzieram się przez nie tak samo jak i przez całego bloga bądź co bądź są to jednakowoż przykłady bardzo złożone
Cytat Hehe, od kiedy to model jest odpowiedzialny za komunikację z bazą danych? Nie bez powodu mówi się, że mechanizm dziedziczenia pozwala na tworzenie bardziej wyspecjalizowanych klas. Specjalizacja = dostosowanie bardziej ogólnej funkcjonalności do bardziej szczegółowego przypadku, a nie dodanie nowej funkcjonalności. Czy pobranie produktów jest jedną z operacji służących do komunikacji z bazą danych? Nie. Ono z tej komunikacji jedynie korzysta, czyli nie używamy dziedziczenia. odnośnie jeszcze tego, rozumiem, że model ma sobie wyciągnąć z klasy DB uchwyt połączenia z bazą po prostu, ale same zapytania do bazy
pozostają w model czy też lądują w klasie DB i przy ich użyciu model te dane pobiera? Ten post edytował olechafm 27.05.2011, 11:38:14 |
|
|
27.05.2011, 12:58:39
Post
#10
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Czy samochód jest bardziej wyspecjalizowaną formą silnika? Nie. Samochód jedynie wykorzystuje silnik. Co więcej robi to w sposób transparenty dla użytkownika, innymi słowy dla kierowcy nie jest istotne to czy jedzie samochodem ze silnikiem benzynowym, dieslem czy hybrydą by prowadzić samochód.
Dokładnie to samo powinieneś zrobić tutaj. Model (samochód) powinien wykorzystywać połączenie z bazą danych (silnik) w celu pobrania danych. Natomiast samo połączenie z bazą danych powinno zostać przekazane modelowi w sposób transparenty dla użytkownika (widok / kontroler). Powiedzmy w modelu będziesz miał coś takiego: Natomiast użytkownik tego modelu będzie mógł go wykorzytać robiąc coś w stylu: Gdzie metoda getRepository() jest odpowiedzialna za utworzenie obiektu UserRepository i przekazanie mu połączenia z bazą danych. To tworzenie obiektów i przekazywanie im zależności jest nieco rozbudowane dlatego powinieneś się już teraz zainteresować czymś takim jak dependency injection oraz DIC. |
|
|
27.05.2011, 13:09:52
Post
#11
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
|
|
|
27.05.2011, 13:21:20
Post
#12
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Nie, to jest zwykły obiekt. Generalnie całego kontenera nie powinno się przekazywać - czasami jest to gdzieniegdzie konieczne ale rzadko.
Zainteresuj się tym: http://components.symfony-project.org/dependency-injection/ - naprawdę fajne narzędzie. |
|
|
27.05.2011, 13:26:06
Post
#13
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 2 Dołączył: 8.10.2010 Skąd: Poniemieckie miasto przesiedleńców Ostrzeżenie: (0%) |
dzięki, czytam też to: www.rekurencja.pl/php/symfony2/czym-jest-dependency-injection.html
Ten post edytował olechafm 27.05.2011, 13:30:10 |
|
|
Wersja Lo-Fi | Aktualny czas: 24.04.2024 - 05:59 |