Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Ocena skryptu.
Forum PHP.pl > Forum > PHP > Object-oriented programming
arrtxp
Witam, czytając o MVC, stworzyłem własne rozwiązanie i chciałbym abyście oceni mój kod, gdzie mniej więcej przedstawiam system działania:

// struktura najważniejszych plików
  1. /a-control // folder gdzie mamy klasy
  2. + klasy
  3. /mod-view // folder z plikami html
  4. + pliki z html
  5.  
  6. index.php


index.php

  1. <?php
  2. header('Content-type: text/html;charset=utf-8');
  3. date_default_timezone_set('Europe/Warsaw');
  4.  
  5. include('./a-control/aStart.php'); // klasa, która waliduję mi dane (np: aStart::spr_int($dane);) i w niej ustawiam połączenie z bazą.
  6. include('./a-control/aLoadClass.php'); // jak sama nazwa mówi
  7.  
  8. // ustawienia loadera class
  9. $firstLoader = new ClassLoader('i', './a-control/');
  10. $firstLoader->register();
  11.  
  12. // generowanie strony
  13. if(empty($_GET['v'])) { $_GET['v'] = 'start'; }
  14. $u = iPage::loadClass($_GET['v']); // wywołanie odpowiedniej kasy
  15. $u->view();
  16. ?>


iPage.php // ustala to co ma być wyświetlone
  1. <?php
  2. abstract class iPage
  3. {
  4. public static $_page = 'start';
  5. public $fd_www = '/www/'; // folder z strona
  6. public static $db_key = 'baza'; // baza danych - prefix
  7. public $_msg = '';
  8.  
  9. // wyczytywanie odpowiedniej klasy
  10. public static function loadClass($page)
  11. {
  12. self::$_page = aStart::spr_txt($page);
  13. $i_class = array(
  14. 'index' => 'iView_Index',
  15. );
  16.  
  17. if(!empty($i_class[self::$_page]))
  18. {
  19. return new $i_class[self::$_page];
  20. }
  21. else
  22. {
  23. return new iStart;
  24. }
  25. }
  26.  
  27. // generowanie strony
  28. public function view()
  29. {
  30. $file = $this->fd_www.'/mod-view/'.self::$_page.'.php';
  31. if(file_exists($file))
  32. {
  33. include($file);
  34. }
  35. else
  36. {
  37. self::$_page = 'error';
  38. include($this->fd_www.'/mod-view/error.php');
  39. }
  40. }
  41. // koniec
  42. }
  43. ?>


a-control/iView_Index.php
  1. <?php
  2. class iStart extends iPage
  3. {
  4. public function __construct() {
  5. // tutaj sobie sprawdzam co ma być wywołane, np:
  6. if(isset($_GET['zaloguj'])) { $this->zaloguj(); }
  7. }
  8. public function zaloguj()
  9. {
  10. // zapytanie do bazy, czy coś w tym stylu
  11. }
  12. public function dom()
  13. {
  14. return 'Ale Twoja chata to ruina.';
  15. }
  16. }
  17. ?>


mod-view/index.php - widok

  1. <html>
  2. <head>
  3. <title>Dom</tilte>
  4. <//head>
  5. <body>
  6. <?php echo $this->dom(); ?>
  7. </body>
  8. </html>


Teraz chciałbym dowiedzieć się czy takie rozwiązanie jest złe. Jakie stwarza problemy takie rozwiązanie?
Daimos
1. Gdzie przekazujesz zmienne do widoku? Bo chyba o tym zapomniałeś.
2. Jak przekażesz z kontrolera np. tytuł strony do szablonu?
3. Jedna z metod Twojego kontrolera zwraca string, dlaczego, po co?
4. MVC, gdzie model? smile.gif
5.
Cytat
/a-control // folder gdzie mamy klasy
nie klasy tylko klasy kontrolera, bo w katalogu np. a-model będziesz trzymał też "klasy", ale chodzi o modele.
6.
Cytat
  1. $i_class = array(
  2. 'index' => 'iView_Index',
  3. );
  4.  
  5. if(!empty($i_class[self::$_page]))
  6. {
  7. return new $i_class[self::$_page];
  8. }

Czyli patrząc na to, każdy kontroler musisz zapisać tutaj w tablicy. Inaczej go nie uruchomisz. Po co w każdym kontrolerze, ładować pełną listę, np. 50-100 kontrolerów ?
Ustal nazewnictwo plików, a następnie sprawdzaj, czy kontroler istnieje jako plik. Później sprawdź czy jest tam wywoływana klasa / metoda. Do tego musisz napisać jakąś "klasę", która zajmie się wszystkim. Nie rób wszystkiego w KAŻDYM kontrolerze.
arrtxp
ad:
1. Nie muszę, wszystko dzieje się w obiekcje, po dane sięgam poprzez - $this->coś
5. Dlaczego nie mogę trzymać wszystkiego w jednym miejscu ?
6. Z tym 1 masz rację.

  1. Do tego musisz napisać jakąś "klasę", która zajmie się wszystkim. Nie rób wszystkiego w KAŻDYM kontrolerze.


klasa abstrakcyjna o nazwie iPage robi wszystko, czyli ustala " moduł " i " widok ".

Ogólnie to działa w ten sposób, np: strona.pl?v=news&nowy

poprzez iPage::loadClass($_GET['v']); następuje wyczytanie klasy i utworzenie obiektu.
A w tej klasie np: News poprzez __construct() następuje załadowanie odpowiednich danych/ wywołanie metod (przez $_GET['news']), które są ładowanie do widoku.
To wszystko tworzy całość.

Czy te rozwiązanie ogranicza mnie w jakiś sposób ? wg mnie, nie (albo nie mam o tym pojęcia, dlatego się pytam). Tworzę widok, klasa obsługująca i mam dodane rozszerzenie. I pytam się czy takie rozwiązanie mnie ogranicza i czy jest złe ? Jak tak to dlaczego ?
Daimos
Zacznijmy od tego, czym jest widok, kontroler i model.
Jeden kontroler nie służy do obsługi całej aplikacji. Powinieneś mieć jakiegoś bootstrapa, klasę która odpowiada za request, routing itp. Najlepiej jakbyś podejrzał jak to jest rozwiązane w innych frameworkach.
Kontroler powinien posiadać jak najmniej kodu, każda akcja powinna odpowiadać za konkretny request. Nie faszeruj kontrolera całym szkieletem aplikacji. Kontroler nie odpowiada za to, jaki kontroler uruchomić, zresztą czytając to na głos, słychać jawnie problem logiczny smile.gif

Analizując Twój kod, to Twoja klasa iPage działa jak bootstrap, obsługa żądania, routing. Wybierasz tam jaki kontroler uruchomić, jaką metodę. Więc zupełnie zbędne jest, aby każdy kontroler po tym dziedziczył.

Podsumowując, koniecznie przyjrzyj się jak rozwiązują te problemy inne FW
Spawnm
  1. iPage::loadClass
  2. aStart::spr_txt()
  3. return new iStart;


Bardzo intuicyjne nazwy.
Samego kodu klas w pełni nie udostępniłeś, więc trudno ocenić.
Poczytaj o mvc i naucz się jakiegoś fw zanim zajmiesz się dalszym rozwojem swojego.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.