Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Czy idę dobrą drogą ?
Forum PHP.pl > Forum > PHP
zielu001
Witam,

Chciał bym się tutaj od was dowiedzieć, a raczej sprawdzić waszą opinię, na temat tworzonej prze zemnie aplikacji smile.gif

Dał bym wam tutaj kod całej aplikacji, ale zhańbicie mnie za brak komentarzy biggrin.gif Więc dam tutaj to o co mi najbardziej chodzi :0 bo zaraz muszę iść bo kupuję auto i jadę obejrzeć.


Tak więc:

Czy mój pomysł i wykonanie klasy Services jest jako tako dobrym pomysłem ? Proszę też podać opinie co by było lepsze

Zawiera wszystkie moduły, które będą istnieć w aplikacji - jest to tak jak by klasa 'globalna' którą dziedziczę w każdym module i subapplikacji

Tutaj klasa:

http://pastebin.pl/98ea402f3821b5a688938600644705df



Tutaj daję Controller - jest to klasa startowa aplikacji, zbiera i uruchamia wszystkie najważniejsze moduły, konfiguruje aplikację do przyjęcia subapp

http://pastebin.pl/b0da971b8c165e15df693a8e6725edff

Tak jak wyżej - dobry pomysł ?


Tutaj pyt: Czy ładowanie sub aplikacji w taki sposób (klasa niżej ) jest dobre i praktyczne?

http://pastebin.pl/47b3e9317425e238dfb8ced5485f9c97


Proszę o odp smile.gif
Dipter
Pierwsza klasa:
1. Niepotrzebnie jest statyczna, poza tym skoro używasz statycznych metod używaj static *typ* function zamiast *typ* function.
2. Metody takie jak Database, Router, Session itp. to dość dobry pomysł, ale lepiej jakbyś użył do tego jakiegoś kontenera (Poczytaj o DependencyInjection).

Druga klasa:
1. "class Controller extends Services" - Nie powinno być takiego dziedziczenia, ty nie rozszerzasz serwisów, tylko z nich korzystasz/robisz na nich operacje - Przekaż obiekt Services poprzez konstruktor/metodę do obiektu Controller.
2. Nie zauważyłem byś gdziekolwiek przekazywał jakąkolwiek konfigurację, a to poniekąd zły znak.

Trzecia klasa:
1. Ten sam błąd co w klasie wyżej, pkt. 1
2. Skoro korzystasz z jakiejś ścieżki kilkukrotnie to zapisz ją gdzieś do zmiennej i używaj w ten sposób. Poza tym lepiej byś tę ścieżkę przekazał jako argument / klucz konfiguracji, zamiast ustawiać na sztywno w klasie.
3. Do tworzenia obiektów przyda Ci się call_user_func_array lub ReflectionClass.
4. Porozdzielaj metode Run() na inne, wyspecjalizowane metody dla poszczególnych elementów ponieważ robi się bałagan.
5. Dane imho nt. modułu itp powinny zostać wcześniej sprawdzone (długość, czy to string itp) i dopiero później powinny być przekazane do Applications w celach sprawdzenia istnienia i utworzenia obiektu.
zielu001
Cytat
"class Controller extends Services"


Myślałem że w ten sposób rozszerzam klasę Controller, a nie Services tongue.gif, Ale trudno..
W każdej innej klasie, nawet sub aplikacji korzystam z extends Services, i dostaję wtedy dostęp do wszystkich zasobów i modułów.
W tedy w każdym miejscu mogę użyć $this->Database()->select( /* args */);
Klasa nie może być statyczna, lecz tylko zmienna w której przechowuję dane o modułach czyli zmienna Services::$_modules.
W ten sposób zapobiegłem duplikowaniu modułów przy każdym dziedziczeniu w klasach.

"Nie zauważyłem byś gdziekolwiek przekazywał jakąkolwiek konfigurację, a to poniekąd zły znak. "

Cytat
$this->Data()->getVars();


Tutaj zbieram dane od clienta i jego przeglądarki.

A w module Config() trzymam całą konfiguracje, stałą i zmienną, która jest dopasowywana do każdej sesji. Nie wiem czy to dobrze, ale liczę na ostrą krytykę tongue.gif
Cytat
Dane imho nt. modułu itp powinny zostać wcześniej sprawdzone (długość, czy to string itp) i dopiero później powinny być przekazane do Applications w celach sprawdzenia istnienia i utworzenia obiektu.


Dane są sprawdzane, te od clienta, ale nie pod kątem aplikacji i typów bo to tak jak by zbieranie i filtrowanie wszystkich dostępnych zmiennych globalnych i sprowadzenie ich do zmiennej w klasie Data. Ale pomyślę nad tym biggrin.gif Co to dodać linijkę czy dwie na sprawdzenie czy w urlu app, module, section są stringami, mają odpowiednią długość itp .

Cytat
Skoro korzystasz z jakiejś ścieżki kilkukrotnie to zapisz ją gdzieś do zmiennej i używaj w ten sposób. Poza tym lepiej byś tę ścieżkę przekazał jako argument / klucz konfiguracji, zamiast ustawiać na sztywno w klasie.


Wiem, wiem, ale to było dla testu i zapomniałem biggrin.gif Zrobi się, dzięki za uwagę.

DependencyInjection
Już to przerabiałem w starej aplikacji.. ale nie wiedziałem że tak to się nazywa. Ale nie wiem czy mi to da taką elastyczność jak tymczasowe rozwiązanie. Muszę pomyśleć.


Dipter
Cytat
W każdej innej klasie, nawet sub aplikacji korzystam z extends Services, i dostaję wtedy dostęp do wszystkich zasobów i modułów.
W tedy w każdym miejscu mogę użyć $this->Database()->select( /* args */);

Tylko, że nie jest to poprawne dziedziczenie.

  1. <?php
  2. class Controller
  3. {
  4.  
  5. private $services = null;
  6.  
  7. public function __construct(Services $services)
  8. {
  9. $this->services = $services;
  10. }
  11.  
  12. public function run()
  13. {
  14. $config = $this->services->getConfig();
  15.  
  16. // ...
  17.  
  18. $this->services->getDatabase()->connect($config);
  19. $this->services->getSession()->init();
  20.  
  21. // ...
  22. }
  23.  
  24. }


Cytat
Dane są sprawdzane, te od clienta, ale nie pod kątem aplikacji i typów bo to tak jak by zbieranie i filtrowanie wszystkich dostępnych zmiennych globalnych i sprowadzenie ich do zmiennej w klasie Data. Ale pomyślę nad tym Co to dodać linijkę czy dwie na sprawdzenie czy w urlu app, module, section są stringami, mają odpowiednią długość itp .

Chodziło mi o coś na zasadzie
- Walidacja danych (długość, typ, znaki specjalne etc)
- Przekazanie ich do klasy Applications
- W tejże klasie sprawdzenie na podstawie danych czy plik i klasa modułu istnieje.
- Odpalenie całości

Cytat
DependencyInjection
Już to przerabiałem w starej aplikacji.. ale nie wiedziałem że tak to się nazywa. Ale nie wiem czy mi to da taką elastyczność jak tymczasowe rozwiązanie. Muszę pomyśleć.

Tak się składa, że da Ci to najbardziej elastyczne rozwiązanie.
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-2025 Invision Power Services, Inc.