[PHP]podział na klasy Opcje

[perhydrol]

Witam,

od jakiegoś czasu eksperymentuję z obiektowym PHP, jednak moje strukturalne myślenie skutecznie mi to utrudnia.
Tylko proszę nie odsyłajcie do przeszukiwania tematów jak wielokrotnie twierdzicie iż temat był poruszany tysiące razy,
ja jednak szukając odpowiedzi w postach już istniejących na tym forum nie znalazłem satysfakcjonującej odpowiedzi.

Mam prośbę, czy mógł by ktoś mi wypisać na przykładzie sklepu internetowego podział na klasy, oraz zakwalifikować je do odpowiednich części:
Model, View, Controller

Coś w stylu listingu klas, i nie jest to z mojej strony wyręczanie się Wami, a jedynie chciał bym dostrzec jak szczegółowo należy podejść do podziału danej dziedziny sklepu internetowego na klasy. Dzięki przypisaniu ich do odpowiednich części MVC, myślę że będę mógł szybciej i lepiej zrozumieć to z czym się borykam. Dodam może że do UML-a używam "NetBeans IDE 6.7.1"

a interesujące mnie rozwiązanie to coś w stylu:

[PHP] pobierz, plaintext 
class DB_Connect           // klasa inicjująca połączenie z baza danych
class DB_View               //  klasa zapytań do bazy danych 
....                               //   tu kolejne pytanie czy jest sens przechowywać wszystkie zapytania do bazy danych, np SELECT ... w jednym pliku?
....                              //    no i jeszcze jak by mógł mi ktoś zaznaczyć która klasa do jakiej części modelu MVC się zalicza
[PHP] pobierz, plaintext 

Ten post edytował nospor 14.10.2009, 23:08:53

[jmail]

no dr4ko wreszcie się z czymś zgadzamy (IMG:style_emoticons/default/biggrin.gif) potwierdż rejestrację i inne duperele powinny być nie w senderze tylko w kontrolerze rejestracji na przykład.

tak samo jak notacja wielbłądzia (IMG:style_emoticons/default/tongue.gif) ja bym to jeszcze przemieszał z notacją węgierską dla pełni szczęścia.

czyli dla przykładu

intJakasZmienna - zawsze wiemy jaki typ reprezentuje

perhydrol nie wiem czy zauważyłeś ale constructor chyba z podwójnym podkreśleniem powinien być zanotowany (IMG:style_emoticons/default/winksmiley.jpg)

jeżeli ja miałbym to rozdzielać (IMG:style_emoticons/default/winksmiley.jpg) to bym to zrobił tak (na przykładzie Twojej klasy zamówienie)

[PHP] pobierz, plaintext 
 
<?php
 
class Zamowienia_kontroler{
    function __constructor()
      {..........}
    function dodajZamowienieDoBazyDanych() //---a może ta metoda powinna być w klasie kontroler (IMG:style_emoticons/default/questionmark.gif) 
      {..........}
    function dodajPunktyRabatuUzytkownikowi()
      {..........}
    function odejmijPunktyRabatuUzytkownikowi()
      {..........}
    function zmienStatusZamowienia() //---jeśli DotPay potwierdził
      {..........}
    function przygotujListeZamowienUzytkownika($intId /*zakładam, że loosera podajesz przez jego id*/)
      {
        /*zakładam, że klasa globalna wykonywania zapytań na bazie danych jest utworzona i że wiesz co chcesz tutaj zrobić
        
        Właśnie taka budowa - w mojej opinii sprawia, że model nie ma pojęcia o kontrolerze i o widoku. poproszony jest o konkretne dane (wywołane są odpowiednie jego funkcjonalności) 
        
        */
        $klasaBazy->parseQuery($parametry, $znacznikQuery); /* bez względu na to co jest pod spodem do model ma wiedzieć jak sparsować takie query - ty masz do środka przekazać parametry i znacznik które query cię interesuje */
        $klasaBazy->executeQuery($znacznikQuery); //przykładowa nazwa - tu każesz modelowi pobrać te dane. 
        $wyniki = $klasaBazy->grabData(); //tutaj zasysam dane - i je chwytasz
        /*
        
        tu następuje ich przetworzenie - robisz na nich to co potrzebujesz co w ostateczności ustawia nam jakąś $tablica
        
        */
        $this->przygotujDlaWidoku($tablica, 'template_jaki_ma_byc_parsowany');
      }
    function przygotujSzczegolyZamowienUzytkownika()
      {..........}
    function przygotujListeZamowienWszystkich() //---w PA
      {..........}
    function przygotujSzczegolyWybraneZamowienie() //---w PA nie wiem czy to jest w ogóle potrzebne - czy to nie dubluje funki ze szczegółami zamówień użytkownika?
      {..........}
    function przygotujDlaWidoku($parse, $template){
        $widok = new globalnaKlasaWidoku($template);
        $widok->assignVars($parse); 
        $widok->view->display();
    }
}
 
class globalnaKlasaWidoku{ /* dlaczego globalna? ponieważ uważam, że Widok również nie powinien być świadomy kontrolera. On daje funkcjonalności, które pozwalają wyświetlić dane w sposób jaki tego oczekujemy, ale tworzenie widoku dla każdej klasy jest zbędne moim zdaniem. Jak już mówiłem wcześniej - cała logika dzieje się w kontrolerze, model dostarcza danych, widok je wyświetla, a kontroler musi to powiązać ze sobą */
    $this->module = '';
    public function __constructor($module){
        $view = new Smarty(); //zakładam wykorzystanie Smartów i funkcji __autoload
        $this->module = $module;
    }
 
    public function assignVars(&$parse){
        foreach($parse as key => $value){
            $this->view->assign($key, $value);
        }
    }
}
 
?>
 
 
[PHP] pobierz, plaintext 

thek -> widzę, ze się całkowicie rozmijamy ze zrozumieniem.

Mnie chodzi o to, że dla mnie baza danych to nie jest konkretny silnik bazodanowy. to nie jest MySQL Postgre XML CSV FB IB SQL Server ORACLE czy bóg wie jeszcze co.

Pokazałem w przykładzie powyżej.

Ja chcę wywołać parseQuery z parametrami i wskazaniem które dane mnie interesują - bez względu na to czy to jest XML, baza danych (w sensie silnika), czy to jest kij wie co.

Na przykład zapisałem sobie w XML'u swoje zapytania do bazy danych (podkreślam ponownie to jest przykład! nie chodzi mi o konkretny silnik bazy danych)

załóżmy

[XML] pobierz, plaintext 
<query id="1">
 select * from {param1} where {param2} =  {param3}
<query>
[XML] pobierz, plaintext 

teraz chcę to wywołać w kontrolerze

[PHP] pobierz, plaintext 
 
$params[1] = 'prametr1';
$params[2] = 'prametr2';
$params[3] = 'prametr3';
$klasaBazy->parseQuery($params, 1); // sparsuj zapytanie 1 (gowno mnie obchodzi czy dla pliku XML czy dla silnika bazy danych czy dla pliku tekstowego - to już ma wiedzieć model z czego korzysta), używając tablicy params
$klasaBazy->executeQuery(); //wykonaj to sparsowane zapytanie - znowu mnie nie obchodzi czy na Oracle'u czy na liczydle
$wynik = $klasaBazy->grabData(); //chcę dostać wyniki niezależne od silnika bazodanowego - chcę dostać prostą tablicę asocjacyjną klucz - wartosc
 
[PHP] pobierz, plaintext 

i teraz sobie mogę na tym wyczyniać co mi się żywnie podoba

Co do na przykład wysyłki. Ja osobiście uważam, że to kontroler musi wiedzieć jakie opcje wysyłki mam możliwe. założmy:

1. GG
2. mail
3. twitter

user przekazuje do kontrolera 4 to co on ma to bez sprawdzenia do modelu przekazać? oczywiście że nie chodzi mi o to, żeby on wykonał mail(). Chodzi mi o to, żeby on wywołał wyslij(typ wysyłki, dane_z_formularza). Ale też musi wiedzieć czy typ wysyłki jest obsługiwany - dzięki temu od razu zwraca userowi błąd


Hmmmmmmm. jak na to wszystko patrzę to chyba chodzi nam o to samo ale inaczej nazywamy (IMG:style_emoticons/default/biggrin.gif) funkcjonalności (IMG:style_emoticons/default/biggrin.gif)

Ten post edytował jmail 16.10.2009, 00:29:18