Kilka pytań o praktyczne zastosowanie programowania obiektowego Opcje

[Crozin]

Z tego co widzę PDT niestety nie udostępnia czegoś takiego ("czyste" - dla Javy - ma).

Podstawowa zaleta getterów o której tutaj nikt nie wspomniał to:
1) Zapewnienie, że podane dane są poprawne. PHP nie jest językiem, w którym typy mają jakieś większe znaczenie, przez to w pole publiczne można wrzucić dosłownie wszystko
2) Gettery/settery to miejsce, w którym można przed przypisaniem/zwróceniem danych zrobić sporo operacji - czasami dodaje się coś dopiero "później", gdy projekt jest już gotowy. Dzięki temu zew. API obiektu się nie zmienia.

[IceManSpy]

A mnie zastanawia jedna rzecz odnośnie programowania obiektowego, a konkretnie obsługa bazy danych. Jak to ogólnie wygląda? Np połączenie i wybranie wszystkich wierszy z tabeli? Co takiego?

[PHP] pobierz, plaintext 
public function pobierz()
{
$tablica = mysql_query("SELECT * FROM `tabela`");
return $tablica;
}
[PHP] pobierz, plaintext 

A jak np robić wyświetlanie wyników w html po pobraniu danych z bazy?

[darko]

A mnie zastanawia jedna rzecz odnośnie programowania obiektowego, a konkretnie obsługa bazy danych. Jak to ogólnie wygląda? Np połączenie i wybranie wszystkich wierszy z tabeli? Co takiego?

[PHP] pobierz, plaintext 
public function pobierz()
{
$tablica = mysql_query("SELECT * FROM `tabela`");
return $tablica;
}
[PHP] pobierz, plaintext 

A jak np robić wyświetlanie wyników w html po pobraniu danych z bazy?

1. Funkcja mysql_query zwraca zasób, a nie tablicę.
2. Generalnie mechanizm jest prosty: w kontrolerze odwołujesz się do modelu - w odpowiedzi na żądanie użytkownika (wywołanie jakiejś akcji) - wywołujesz odpowiednie metody modelu pobierające dane z bazy, następnie przekazujesz - najczęściej tablicę (z danymi) - do widoku, w którym wyświetlasz po kolei, czy jak tam potrzebujesz pobrane dane.
3. To, co nazywasz obsługą bazy danych to odpowiednia klasa modelu, umożliwiająca - w najprostszej formie - podstawowe operacje CRUD na rekordach. Najczęściej użytym wzorcem modelu DB jest singleton (słusznie czy niesłusznie, osobiście uważam, że powinna istnieć tylko jedna instancja obiektu reprezentującego bazę danych).
Najlepiej podejrzyj jakieś rozwiązania frameworkowe Kohana, klasy z rodziny Zend_Db_XXX. Zastosowane tam rozwiązania są dość czytelne (mam na myśli Zenda, bo z Kohany nie korzystam).

[IceManSpy]

1. Funkcja mysql_query zwraca zasób, a nie tablicę.

Faktycznie, zapomniałem, bo na szybko pisałem Zaraz sobie pooglądam jak to robi się w zendzie.

[Crozin]

@Darko:

Fail #1: Model MVC w skrócie: wywołanie Kontrolera -> Kontroler określa, że potrzeba użyć tego Widoku i wrzucić mu ten a ten Model(e) -> odpalenie Widoku. Jak widzisz Kontroler nie pośredniczy w przekazywaniu danych do Widoku - on sam potrafi sobie pobrać co mu jest potrzebne.
Fail #2: Ta myśl o tym, że powinna być tylko jedna instancja obiektu obsługującego bazę danych. No to prosta sytuacja, mamy następujące modele:

• Aktualności - pobiera aktualności do witryny z naszej lokalnej bazy danych
• Galeria - pobiera obrazy z naszej lokalnej bazy danych
• Użytkownik - j/w
• Użytkownik::zasugerujListęZnajomych - metoda wykorzystuje Facebookowe API i próbuje zwrócić nam sugerowaną listę znajomych danego użytkownika
• Płatności - nasza aplikacja to np. sklep internetowy z jednym z backendów w postaci aplikacji desktopowej, która operuje na bazie SQLite po czym udostępnia tą bazę na serwerze - tutaj Twoja teza zawodzi po raz pierwszy
• Magazyn - skoro to sklep, to musimy mieć jakiś magazyn - ale ten znajduje się daleko od nas i musimy się połączyć z jego bazą danych - tutaj Twoja teza zawodzi kolejny raz

To, że w zdecydowanej większości przypadków mamy dokładnie jedną instancję obiektu reprezentującego bazę danych (używanego przez różne Modele) nie oznacza, że tak będzie zawsze. Aplikacji korzystających z dwóch lub więcej baz danych na raz, jako tych lokalnych jest względnie niewiele, ale ot system umożliwiający założenie sobie forum czy bloga (który jest w osobnej bazie) - i już masz konieczność wykorzystania obu baz na niektórych podstronach.

Najlepiej podejrzyj jakieś rozwiązania frameworkowe Kohana

Jeżeli zależy Ci na tym by nauczyć się OOP - w kod Kohany v3 nawet nie zaglądaj (musisz się najpierw uodpornić ).

Ten post edytował Crozin 29.07.2010, 13:08:09

[everth]

Wczoraj poczytałem o tym MVC i wyszło na to że cały czas stosuję MVP. Człowiek zawsze się uczy. Swoją drogą nie mogę rozgryźć implementacji czystego MVC - czy to jest tak że mamy wiele modeli (za @Crozinem) i wiele widoków (do wyświetlania danych z modelu?), a jeden Kontroler który tym wszystkim zarządza? Ja robiłem to tak że model wyrzucał dane w formie XML a za Widok robiły szablony XSL - Kontroler ograniczał się do selekcji danych z modelu i wyboru szablonu. Dla mnie to MVP, wydaje się zresztą dosyć proste. Czy czyste MVC dałoby tu jakiekolwiek korzyści?

[darko]

@Darko:

Fail #1: Model MVC w skrócie: wywołanie Kontrolera -> Kontroler określa, że potrzeba użyć tego Widoku i wrzucić mu ten a ten Model(e) -> odpalenie Widoku. Jak widzisz Kontroler nie pośredniczy w przekazywaniu danych do Widoku - on sam potrafi sobie pobrać co mu jest potrzebne.

Taaaak, w idealnej implementacji, która nie istnieje powinien zostać zaimplementowany wzorzec obserwator i widoki powinny się same uaktualniać przy zmianie danych. To wiemy. Niestety praktyka, zwłaszcza frameworkowa oraz specyfika protokołu HTTP uniemożliwiają taką "najbliższą ideałowi" (którego nie ma!) implementację mvc i nie ma co udawać, że jest inaczej Oczywiście, że sam kontroler fizycznie nie przekazuje danych z modelu do widoku, jednak to w nim deklarujemy tę operację:
przykład a'la ZF:
// kontroler
public function xyzAction()
{
// przekazanie danych do widoku (w kontrolerze z modelu sic!)
$this->view->sth = $this->MyModel->getSth();
}
// (...)

// widok:
// xyz.phtml
<!-- (...) -->
<?php
if($this->sth):
foreach($this->sth as $test):
echo $test->x . '<br/>' . $test->y . '<br/>' . $test->z;
endforeach;
endif;
?>

Fail #2: Ta myśl o tym, że powinna być tylko jedna instancja obiektu obsługującego bazę danych. No to prosta sytuacja, mamy następujące modele:

• Aktualności - pobiera aktualności do witryny z naszej lokalnej bazy danych
• Galeria - pobiera obrazy z naszej lokalnej bazy danych
• Użytkownik - j/w
• Użytkownik::zasugerujListęZnajomych - metoda wykorzystuje Facebookowe API i próbuje zwrócić nam sugerowaną listę znajomych danego użytkownika
• Płatności - nasza aplikacja to np. sklep internetowy z jednym z backendów w postaci aplikacji desktopowej, która operuje na bazie SQLite po czym udostępnia tą bazę na serwerze - tutaj Twoja teza zawodzi po raz pierwszy
• Magazyn - skoro to sklep, to musimy mieć jakiś magazyn - ale ten znajduje się daleko od nas i musimy się połączyć z jego bazą danych - tutaj Twoja teza zawodzi kolejny raz

To, że w zdecydowanej większości przypadków mamy dokładnie jedną instancję obiektu reprezentującego bazę danych (używanego przez różne Modele) nie oznacza, że tak będzie zawsze. Aplikacji korzystających z dwóch lub więcej baz danych na raz, jako tych lokalnych jest względnie niewiele, ale ot system umożliwiający założenie sobie forum czy bloga (który jest w osobnej bazie) - i już masz konieczność wykorzystania obu baz na niektórych podstronach.

Jeżeli zależy Ci na tym by nauczyć się OOP - w kod Kohany v3 nawet nie zaglądaj (musisz się najpierw uodpornić ).

Albo ja czegoś nie rozumiem, albo Ty. Nie napisałem nigdzie, że zawsze musi być jedna instancja bazy danych i uparcie będę twierdził, że - nawet jeśli zdefiniujemy różne dane konfiguracyjne - to i tak powinniśmy mieć możliwość - przy zastosowaniu jednej instancji obiektu bazy danych - "przełączania się" pomiędzy bazami (patrz np. Zend_Application_Resource_Multidb). Tylko dlaczego mieszać kwestię komunikacji z zewnętrznym źródłem danych poprzez wspomniane FB API z modelem DB? Przecież w jakimś innym modelu obsłużysz sobie bez problemu dane z facebooka, z bazą danych nie ma to nic wspólnego, dopóki nie będziesz musiał na tych danych operować, gromadzić je w swojej bazie danych, ale i tu rozwiązanie jest proste - napisanie/użycie odpowiedniego modelu korzystającego z FB API i pobierającego dane. Oczywiście możesz napisać sobie własny pseudo-adapter, w którym będziesz symulować implementację np. metody pobierającej dane - select() gdzie zaimplementujesz pobieranie danych z FB. Grunt, to dostosować się do interfejsu. Dążę do tego, że w przypadku, kiedy mamy wiele źródeł z których pochodzą dane, możemy - trzymając się nadal koncepcji jednej instancji DB - implementować własne adaptery i przełączać się pomiędzy nimi, korzystając z jednolitego interfejsu. W ten sposób mamy możliwość rozróżniania źródła pochodzenia danych. Myślę, że jest to wykonalne.

// edit
można też wykorzystać factory do dynamicznego tworzenia obiektów DB dla poszczególnych źródeł pochodzenia danych.

Ten post edytował darko 29.07.2010, 14:24:55

[Crozin]

Taaaak, w idealnej implementacji, która nie istnieje

Istnieje, istnieje. MVC to nie jest jakaś "niepoznana prawda" tylko konkretny opis jak wykonać dane zadanie. Jednak jak słusznie zauważyłeś w środowisku HTTP nie da się jej zaimplementować (model nie może powiadomić widoku (w sensie tego co jest już wyświetlane użytkownikowi) o zmianie swojego status) - o to się czepiać nie będę (chociaż IMO to już kwalifikuje to skreślenia nazwy MVC na rzecz jakiegoś "passive-view-MVC")

Oczywiście, że sam kontroler fizycznie nie przekazuje danych z modelu do widoku

Problem w tym, że to co pokazałeś w listingu poniżej tego cytatu to przekazanie danych do widoku przez kontroler z modelu. A kontroler powinien przekazać do widoku tylko model. Ale to jeszcze jest do przeżycia... najgorsze jest to, że uprościłeś: Widoku = szablon (czy to HTML czy PDF to bez znaczenia). A to widok jest odpowiedzialny za całą logikę widoku (sortowanie po kolumnach, paginacja itp.) by na końcu dopiero odpalić sobie jakiś szablon i go wyświetlić.

To co pokazałeś ma naprawdę niewiele wspólnego z MVC. To nie jest coś gorszego... to jest coś innego.

W jakimś innym wątku bodajże Zyx całkiem fajnie opisał to.

Albo ja czegoś nie rozumiem, albo Ty. (...)

A tutaj widzę że doszło do małego nieporozumienia.

Najczęściej użytym wzorcem modelu DB jest singleton (słusznie czy niesłusznie, osobiście uważam, że powinna istnieć tylko jedna instancja obiektu reprezentującego bazę danych).

Pisząc coś takiego sugerujesz zrobienie czegoś takiego:

[PHP] pobierz, plaintext 
class Database {
  protected __construct() {
    $this->db = new PDO();
  }
  // implementacja Singletona
}
[PHP] pobierz, plaintext 

A jak rozumiem chodziło Ci o coś takiego:

[PHP] pobierz, plaintext 
class DbManager {
  protected $instances = array();
 
  addInstance($name, Database $db) { $this->instances[$name] = $db; }
  getInstance($name) { return $this->instances[$name]; }
 
  // TUTAJ implementacja singletona
}
 
class Database {
  public function __construct() {
    ///..
  }
}
[PHP] pobierz, plaintext 

W takim przypadku użycie Singletona jest może nie tyle co wskazane co dopuszczalne i przede wszystkim sensowne.

Jednak co do drugiej części to nie możesz zakazać istnienia takiego modelu:

[PHP] pobierz, plaintext 
public function retrieveFriends($id) {
  return $this->facebookAPI->getFriendsOf($id); // FB API
}
 
public function retrieveOne($id) {
  return $this->db->select()->where('id', $id); // Lokalna baza
}
 
public function retrieveSth($id, $def) {
  return $this->db['remote']->select()->where('id', $id)->where('def', $def); // Jakaś baza na innym serwerze
}
[PHP] pobierz, plaintext 

Zrobiłeś jeszcze chyba jeden błąd (nie mam teraz czasu czytać jeszcze raz) - uprościłeś: 1 model = 1 tabela w bazie. A to nie prawda. Model ma sobą obejmować jakieś dane, które niekoniecznie muszą obejmować jedną tabelę.

[darko]

Istnieje, istnieje. MVC to nie jest jakaś "niepoznana prawda" tylko konkretny opis jak wykonać dane zadanie. Jednak jak słusznie zauważyłeś w środowisku HTTP nie da się jej zaimplementować (model nie może powiadomić widoku (w sensie tego co jest już wyświetlane użytkownikowi) o zmianie swojego status) - o to się czepiać nie będę (chociaż IMO to już kwalifikuje to skreślenia nazwy MVC na rzecz jakiegoś "passive-view-MVC")

Jak sam zaznaczyłeś istnieją opisy koncepcyjne, jednak modelowej i jedynej słusznej implementacji MVC nie ma i, uważam, że nie będzie.

Problem w tym, że to co pokazałeś w listingu poniżej tego cytatu to przekazanie danych do widoku przez kontroler z modelu. A kontroler powinien przekazać do widoku tylko model. Ale to jeszcze jest do przeżycia...

Masz rację, powinienem przekazać cały obiekt, zamiast tego, co zwróci metoda:

[PHP] pobierz, plaintext 
$this->view->sth = new MyModel();
[PHP] pobierz, plaintext 

najgorsze jest to, że uprościłeś: Widoku = szablon (czy to HTML czy PDF to bez znaczenia). A to widok jest odpowiedzialny za całą logikę widoku (sortowanie po kolumnach, paginacja itp.) by na końcu dopiero odpalić sobie jakiś szablon i go wyświetlić.

Gdzie? W którym miejscu tak napisałem?

To co pokazałeś ma naprawdę niewiele wspólnego z MVC. To nie jest coś gorszego... to jest coś innego.
(...)
Jednak co do drugiej części to nie możesz zakazać istnienia takiego modelu:

[PHP] pobierz, plaintext 
public function retrieveFriends($id) {
  return $this->facebookAPI->getFriendsOf($id); // FB API
}
 
public function retrieveOne($id) {
  return $this->db->select()->where('id', $id); // Lokalna baza
}
 
public function retrieveSth($id, $def) {
  return $this->db['remote']->select()->where('id', $id)->where('def', $def); // Jakaś baza na innym serwerze
}
[PHP] pobierz, plaintext 

Nie mogę niczego i nikomu zakazać, to nie dyktatura. Na szczęście żyjemy w wolnym kraju

Zrobiłeś jeszcze chyba jeden błąd (nie mam teraz czasu czytać jeszcze raz) - uprościłeś: 1 model = 1 tabela w bazie. A to nie prawda. Model ma sobą obejmować jakieś dane, które niekoniecznie muszą obejmować jedną tabelę.

Spytam ponownie: gdzie? W którym miejscu tak napisałem? Miałem na myśli 1 model == 1 baza danych (+ dane konfiguracyjne) == 1 źródło pochodzenia danych, czyli osobny model dla bazy lokalnej, osobny dla zdalnej i osobny do komunikacji poprzez Facebook API.

[Crozin]

Jak sam zaznaczyłeś istnieją opisy koncepcyjne, jednak modelowej i jedynej słusznej implementacji MVC nie ma i, uważam, że nie będzie.

Koncepcja jest jedna i dobrze opisania. Jedynie na potrzeby WWW (ograniczenia HTTP) usuwa się z niej jeden element: komunikację model ---> widok.

I proszę, przykładowa implementacja MVC z pominięciem powyższego element:
index.php: http://ideone.com/hrPUz
list-template.php: http://ideone.com/gHrjk
table-template.php: http://ideone.com/E9LAW
pagination-partial.php: http://ideone.com/Rg82I

Cały kod kontrolera wyświetlającego tabelkę z użytkownikami, którą można sortować oraz jest ona podzielona na strony:

[PHP] pobierz, plaintext 
class MembersController {
	public function listAction() {		
		$view = new TableView();
		$view->setModel(new MembersModel());
 
		return $view;
	}
}
[PHP] pobierz, plaintext 

Z racji na to, że interfejs przeglądania tabeli jest rozwnięciem interfejsu przeglądania listy zamiana w powyższym kodzie TableView na ListView spowoduje, że użytkownicy wyświetlą się w formie listy, nie tabeli. Chcesz dodać możliwość wyświetlania aktualności w formie tabelki? Wystarczy dodać do modelu NewsModel implementację interfejsu BrowseTableInterface, czyli notabede:

[PHP] pobierz, plaintext 
public function getColumns() {
  return array('id', 'title', 'content');
}
[PHP] pobierz, plaintext 

I już możesz wyświetlać aktualności w formie tabelki. Chcesz by tą tabelkę dało się sortować? Wystarczy dodać interfejs SortableInterface i już.

Gdzie? W którym miejscu tak napisałem?

O tutaj:

[PHP] pobierz, plaintext 
// widok:
// xyz.phtml
<!-- (...) -->
<?php
if($this->sth):
foreach($this->sth as $test):
echo $test->x . '<br/>' . $test->y . '<br/>' . $test->z;
endforeach;
endif;
?>
[PHP] pobierz, plaintext 

Miałem na myśli 1 model == 1 baza danych (+ dane konfiguracyjne) == 1 źródło pochodzenia danych, czyli osobny model dla bazy lokalnej, osobny dla zdalnej i osobny do komunikacji poprzez Facebook API.

No to znowu źle robisz. Interfejs modelu ma kompletnie niezwiązany z wewnętrzną pracą modelu. Ty musiałbyś zrobić dwa modele: MemberModelUsingLocalDatabase, MemberModelUsingFacebookAPI (to jakie one nazwy będą miały nie ma znaczenia).

Ten post edytował Crozin 29.07.2010, 18:37:07

[phpion]

Ja mam pytanko: wychodząc z założenia, że w kontrolerze przekazuję do widoku obiekt modelu, a dopiero w widoku pobieram z niego dane to co w przypadku, gdy będzie konieczna jakaś zmiana w parametrach wywoływanej metody modelu? Wówczas konieczna byłaby zmiana wywołań w każdym widoku, czy tak? Jeśli tak to przekazując dane bezpośrednio w kontrolerze zmiany nanosimy tylko w nim, a widoki dostają już konkretne dane.

[Crozin]

Jest 9 rano, czyli od jakiś 26 godzin jestem na nogach - wybacz jeżeli niezbyt ładnie odpowiem.

Tak, jeżeli potrzebujesz zmienić z jakiś powodów argumenty wywołania danej metody, musisz poprawić interfejs, a co za tym idzie wszystkie wywołania danej metody w aplikacji, czyli np. w widokach.

Jeśli tak to przekazując dane bezpośrednio w kontrolerze zmiany nanosimy tylko w nim, a widoki dostają już konkretne dane.

Ale cała idea polega na tym, że widok nie dostaje danych tylko je sobie sam bierze. Dzięki temu jest on w stanie samodzielnie zadecydować co chcesz wziąć.