@Crozin - co do tego że call_user_func jest wolne to tylko powtarzam zasłyszane . Gdzieś widziałem wyniki jakiegoś bencha którym porównywano eval,call_user oraz bezpośrednie wywołania. Wyszło na to że wywołanie przez eval jest 10 razy wolniejsze niż bezpośrednie a call_user 2,3 raza wolniejsze. Możliwe że poprawili to w nowszych wersjach. Dla mnie jednak call_user_func jest przydatne tylko w określonych zastosowaniach (np. wywoływanie metod za pomocą GET-a).

@everth:
Mój przykład faktycznie był średnio trafiony, zdecydowanie lepszy podał ~Crozin.

Co do wydajności: nie przesadzaj, lepiej skupić się na tym, co faktycznie spowalnia aplikację (np. zapytania SQL). Równie dobrze mógłbyś benchmarkować sobie echo/print czy zrezygnować z foreach().

Argumenty, które podałeś:

można z powodzeniem podpiąć pod bezpośrednie przypisanie wartości do składowych publicznych lub generalnie z pominięciem setterów.

Przecież oczywisty jest, że wywołanie call_user_func będzie wolniejsze od zwykłego wykonania wpisanej w kod metody. Ale tej funkcji, a raczej całego zestawu w postaci: call_user_func(), ReflectionAPI, zmienne zmiennych używa się dopiero w momencie gdy są potrzebne i bez nich nie da się obejść - a zbyt często się to nie zdarza (szczególnie od wersji 5.3, gdy dostępne są funkcje anonimowe znika problem połowy callbacków). Nawet jeżeli call_user_func miałoby być 1000 razy wolniejsze niż "statyczne" wywołanie to nie miałoby to znaczenia. Skrypt spowolniłby o 0.0002 sekundy - taką cenę można bez problemu zapłacić.

Ja cały czas odnoszę się do powyższego zastosowania które dla mnie osobiście jest bez sensu. Poza tym po to są pola public i private żeby stosować je z rozmysłem. Mi osobiście brakuje jeszcze możliwości ustawienia pola readOnly (jak mają wbudowane klasy) - byłoby to wygodne i bezpieczne.

Dla mnie też jest to bez sensu, ale jeśli chcesz ustawiać składowe na podstawie tablicy to jest to sensowniejsze rozwiązanie niż $this->$var = $value.


Jak już wcześniej pisałem: nie używam pól publicznych. Nie widzę takowej potrzeby. Wolę nadać polu widoczność chronioną i dopisać odpowiedni getter. Podaj może przykład, w którym lepiej byłoby zastosować składową publiczną w miejsce protected + getter.

Co do tablicy, to odpuszczam, kwestia przyzwyczajenia. Co do metod publicznych - poza niewygodą dopisywania dodatkowych funkcji i być może narzutem na wydajność - również odpuszczam (w C++ też robię tak jak ty). Tak więc zgoda, obie metody mają swoje wady i zalety a dla mnie to jak dyskusja o wyższości świąt bożego narodzenia nad świętami wielkiej nocy.

Masz rację, jest to dyskusja, w której obie strony mają swoje racje. No ale zazwyczaj na tym polegają dyskusje gdybyśmy oboje uważali to samo to bez sensu byłoby się nad tym rozwodzić

Jeśli chodzi o niewygodę konieczną z dopisywanie setterów/getterów to się w pełni zgadzam (aczkolwiek np. Netbeans potrafi sobie je wygenerować), również jeśli chodzi o wydajność to też masz rację - takie metody będą zawsze ciut wolniejsze od bezpośredniego odwołania do składowej. No ale moim zdaniem są to minusy, które da się przeżyć jeśli pomyślimy o korzyściach płynących z takiego rozwiązania.

Na tym myślę, że możemy zakończyć dyskusję bo nic więcej nie wymyślimy w tej materii. Kto będzie chciał to sobie przeczyta nasze wypowiedzi i wyrobi sobie własne zdanie. Dzięki za debatę

Zaciekawiłeś mnie z tym automatem w NetBeans, nie orientujesz się może czy w Eclipse jest dostępne coś takiego? (Aptana albo PDT)

Korzystam z Eclipse Helios Release Build id: 20100617-1415 i brakuje mi tej opcji w menu Source (albo jestem ślepy). Pamiętam, że w Eclipsie dla Javy taka funkcjonalność była (i jest?).

Niestety chyba nie ma

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.

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).

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

@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.

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

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?

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;
?>


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.

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")

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.

A tutaj widzę że doszło do małego nieporozumienia.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ę.

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


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

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

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




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


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.

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ż.


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 

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).

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.

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.
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ąć.