Obiektowe PHP

[Artur Net]

Aha, w sumie to ja nie planuje w przyszłości robić małych rzeczy tylko większe. Ludzie zaczęli pisać wyżej, że jak ślimak działa, to się zdziwiłem nieźle. Znam człowieka, który zajmuje się tym profesjonalnie i co jakiś czas dostaje kupę zleceń do realizacji. Więc jest wzięcie na takie rozwiązania.

Ja byłem w szpitalu jakiś czas więc miałem przerwę od programowania niestety.

[Mion]

Piszesz, że podstawy znasz, a za chwile pytasz czym się różni ORM od PDO to tak jak być zapytać czym się różni młotek od gwoździa. Taka wiedza to są właśnie podstawy. Nikt nie pisał, że działa jak ślimak, bo tak nie działa, ale z pewnością jakieś koszty się ponosi korzystając z tej technologi.

Poza tym ORM nie wiąże się konkretnie z jakimś językiem w tym wypadku PHP wiec możne twój kolo ma zlecenia jako programista w innych językach np C#

[shad]

A moim skromnym zdaniem ORM w PHP to nie ta klasa aplikacji, ja wolę używać niskopoziomowych zapytań SQL'a przy których mogę zoptymalizować zapytania. Bo jak wykonuje się dużo operacji na DB to każda pośrednicząca warstwa to spadek wydajności. Przykład przy testowaniu sqlite, zapytania idące przez PDO o 50% wolniejsze idące przez natywnego klienta.

[kilas88]

Wszystko zależy od budowanej aplikacji. ORM jest dużo dużo dużo prostszy w obsłudze, operawanie na bazie prościutkie i przyjemne. Ma to jedną główną niekorzyść - wydajność maleje. Jednak jak często się powtarza: praca człowieka jest ważniejsza i cenniejsza niż praca maszyny. Także budując małą stronę domową możesz śmiało walić w ORM-y. Budując jednak aplikacje, która będzie działać pod dużym obciążeniem powinieneś raczej skorzystać z PDO, tak by operować na niższej warstwie abstrakcji.

W zależności od aplikacji, nawet przy tych działających pod dużym obciążeniem można szukać alternatywnego rozwiązania, tak by był wilk syty i owca cała (mało pracy komputera, mało pracy człowieka) mowa tutaj o różnego rodzaju buforowaniu danych, tworzeniu cache, wykorzystywaniu narzędzi typu mem cache, etc. Jeśli strona jest stosunkowo statyczna i nie wymaga cągłego ładowania wszystkiego z bazy, można korzystać z ORM.

[Mion]

Przykład przy testowaniu sqlite, zapytania idące przez PDO o 50% wolniejsze idące przez natywnego klienta.

A ten natywny klient to według Ciebie jaki jest ? Poza tym jak te testy były prowadzone.

ORM jest dużo dużo dużo prostszy w obsłudze, operawanie na bazie prościutkie i przyjemne.

Dużo prostszy, ale od czego ? Co może być "jeszcze prostsze" od wywołania funkcji do usługi MySQL, lub jak ktoś woli zamiast [] pisać -> MySQLI dostępnych w PHP, lub PDO z PHP ?

[slawek22]

Co takiego napisałem, że mi piszecie żebym się podstaw uczył? Znam podstawy. Przypominam ze to jest forum publiczne i proszę mnie nie obrażać (do slawka).

Czym się różni PDO od ORMa?

Człowieku. Piszesz w google ORM, piszesz PDO. Masz przynajmniej 5 dobrych stron o tym na 1 stronie wyników. Co nam za chwilę napiszesz, "czym komputer się różni od telewizora"?

Jak sam nie potrafisz dojść mniej więcej do tego o co chodzi i zadać konkretnego pytania (np. jak jest z wydajnością czy czasem programisty w projektach, bo sam tego nie sprawdzisz, bo np. tydzień temu zainstalowałeś php i nie umiesz)... to albo masz 8 lat albo daj sobie z tym spokój. Taka praca wymaga samodzielności, z resztą na to pytanie sama odpowiedziałaby sobie osoba która skończyła 8 lat.

Nie wiem, może adminka zatrudniła trzecioklasistę do "rozkręcania forum" jeśli tak to sorry, ale lepiej popisz o pokemonach, zawsze lepiej poczytać jakieś ciekawe historie niż patrzeć jak ktoś nie potrafi 2 minuty posiedzieć z google, żeby sprawdzić, że nie ma czegoś takiego jak "obiektowe połączenie z bazą danych"

[kilas88]

ORM jest dużo dużo dużo prostszy w obsłudze, operawanie na bazie prościutkie i przyjemne.

Dużo prostszy, ale od czego ? Co może być "jeszcze prostsze" od wywołania funkcji do usługi MySQL, lub jak ktoś woli zamiast [] pisać -> MySQLI dostępnych w PHP, lub PDO z PHP ?

Jest prostszy i szybszy od pisania w "gołym" SQL. W dodatku dużo bardziej czytelny (refaktoryzacja i te sprawy). Przykład prostoty:

$client = new Client();
$client->setUserID	( $_POST['userID'   ]);
$client->setEmail	 ( $_POST['email'	]);
$client->setFirstname ( $_POST['firstname']);
$client->setLastname  ( $_POST['lastname' ]);
$client->setAddress1  ( $_POST['address1' ]);
$client->setAddress2  ( $_POST['address2' ]);
$client->setCity	  ( $_POST['city'	 ]);
$client->setProvince  ( $_POST['province' ]);
$client->setCountry   ( $_POST['country'  ]);

if ($client->submit($db) !== true)
{
// do error handling
}

[Mion]

Przykład jaki Podajesz kompletnie nic nie przywiesza,a ni ułatwia pracy z bazą danych - Czysta sztuka dala sztuki....

[slawek22]

Jak masz kilka kwerend to wszystkie dane są w jednym obiekcie, kod jest czytelniejszy. Chociaż lepiej:

$fields = array('id'=>1, 'v1'='x', ....)

$db->data = $fields;

$db->query("SELECT ... WHERE id=:id:");

$db->query("INSERT ... VALUES ... (:v1:,:v2:,:v3:);

Poza tym powyższy kod to overkill (wygląda trochę jak kod klasy w C++). Lepiej wszystkie dane ustawiać w konstruktorze, php to dynamiczny język, nie trzeba wszystkiego aż tak obudowywać

Z resztą getters/setters się stosuje raczej tam gdzie potrzeba walidacji albo ustawienie wartości powinno wygenerować jakąś akcję.

[kilas88]

Hmm.. dla mnie jest dużym ułatwieniem. Może kwestia przyzwyczajenia Umiem pisać w czystym SQL, ale znacznie bardziej czyta mi się powyższy kod, niż standardowo coś typu:

INSERT INTO Client (UserID, Email, Firstname, ...)
VALUES ($_POST['userID'], $_POST['email'], $_POST['firstname'], ...)

W czystym SQL dochodzi potrzeba samodzielnego zabezpieczania przed atakami typu SQL Injection, natomiast ORM zazwyczaj same robią to w tle.

Btw. https://blog.webarchitect.pl/2008/02/23/jed...doktryna-w-php/

Kolejne korzyści. Nie chcę powielać różnych zalet, gdyż łatwo o tym znaleźć i poczytać w Internecie.

Btw. wzorce projektowe są to po, by pomagać programistom. Active Record zdecydowanie należy do tych, których znajomość przydaje się w życiu zawodowym programisty. Odpowiadając więc na początkowe pytanie w temacie - lepiej poznać ten wzorzec. Stosować w zależności od okoliczności.

Z resztą getters/setters się stosuje raczej tam gdzie potrzeba walidacji albo ustawienie wartości powinno wygenerować jakąś akcję.

Gettery i settery mają za priorytet ułatwienie refaktoryzacji kodu. Oczywiście pomagają również odfiltrowywać nieporządane dane trafiające do klasy, jak i wykonywać inne akcje. Również ideologia obiektowa i dobre praktyki kodowania przemawiają za stosowaniem get/set. Ustrzega to przed odwoływaniem się do nieistniejących właściwości - lub tworzyć nowe, które później są trudne do wychwycenia i aktualizacji, przy ewentualnych poprawkach/modyfikacjach.

[Mion]

@W czystym SQL dochodzi potrzeba samodzielnego zabezpieczania przed atakami typu SQL Injection, natomiast ORM zazwyczaj same robią to w tle.

Jeśli posiadasz własny zestaw klas do filtracji porostu go stosujesz. Jeśli zachodzi potrzeba budowania berdzie złożonych zapytań nie znam lepszego narzędzia niż program MySQL Query Browser w którym metodą "drag and dro" buduje się zapytanie i co więcej od razu można je przetestować. IMHO taki sposób jest znaacniieeeeeeee szybszy niż ich składanie w inny sposób. Do tego samo wykonie zapytanie nie wiąże się z innymi operacjami w php takimi.

Jak już ktoś koniecznie chce to nawet w kohana jest Object Relational Mapping (ORM) dostępny

[kilas88]

Mion, dlatego wspomniałem, że nie dla wszystkich stron warto stosować ORM. Jeśli zamierzamy tworzyć skomplikowane zapytania do bazy danych, pobierać często lub dużo danych czy tworzyć inne zaawansowane i rozbudowane systemy - lepiej posłużyć się PDO lub mysqli

[Artur Net]

No nie powie, taki program co podałeś dla przykładu, MySQL Query Browser, że można budować zapytania jest przydatny i kształcący. Zwłaszcza, że nie wszystko się człowiek nauczy od razu, i niektóre rzeczy jak ktoś nie wytłumaczy to nie przebrnie tego w pojedynkę. A z pytaniem się na forum, jak sami widzicie, najczęściej kończy się odzewem typu: "ty idioto nie potrafisz się sam tego nauczyć....".

Zainstalowałem, ostatnio visual studio 2010 U b2, przerabiają intellisense, w becie nie ma dostępu do niego ... szukałem jakiegoś patcha, ale nic nie nalazłem na razie.

[slawek22]

Trochę przykro to stwierdzać, ale najczęściej to chyba w twoim przypadku. Jeszcze smutniejsze jest to, że chyba nie wiesz dlaczego.

Sorry ale to nie korespondencyjny kurs podstaw obsługi komputera dla kucharek i sprzątaczek a zadanie konkretnego pytania to chyba na prawdę niewiele, skoro 99,99% użytkowników tego forum to potrafi. Jeśli już nie konkret to przynajmniej jakaś rozmowa a nie gadanie od rzeczy. Nie wiem czy potrafisz czytać - chyba nie bo zadajesz ogólne pytanie a potem kolejne ogólne pytanie baz żadnego odniesienia do poprzednich odpowiedzi.

Albo te odpowiedzi cię nie interesują albo nie potrafisz ich zrozumieć. Bo nie wiem co ma ORM do Query Browser, Intellisense w Visual Studio wydawania patchy przez microsoft, etc, etc.

Podsumowując: naucz się czegoś porządnie lub chociaż przeczytaj 5 stron książki o czymkolwiek, bo mam wrażenie, że wpisujesz definicję w wikipedii, czytasz 2 linijki hasła a potem chcesz o tym gadać. Dostajesz parę odpowiedzi 'o już umiem ORMA - no to teraz na forum mnie nauczom Visual Studio'

Albo po prostu pisz bloga. Forum != Blog.

[Artur Net]

ORM do Query Browser? Oba ułatwiają formowanie zapytań do bazy? Nie byłeś na tyle bystry, żeby to dostrzec ?