Niestety wszystko sie tu nie zmiascilo, wiec zalaczam wrzutke do krytyki
http://wklej.org/hash/a36cc42ed55/
Klasa Statement nie ma najmniejszego sensu.
Przekazujesz do niej obiekt $pdo oraz statement i jedyne co ona robi to sprawdza czy jest polacznie pdo.... Hello, jesli masz juz statement to polaczenie bylo inaczej bys nie mial statement.
Kolejna rzecza ktora robi to tylko wywolanie metod ala fetch() i na dodatek lapiesz tam wyjatki. metody fetch nie rzucaja wyjatkow, nie ma co lapac. Wyjatki sa na etapie prepare i execute co ty masz poza klasa.
Takze generalnie bez sensu jest tworzenie takiej klasy gdzie ona praktycznie nic nie robi a wiekszosc roboty jest zrobiona poza klasa. Reszty kodu nie przegladalem
Zamysl byl taki, aby po wykonaniu $db->connect mozna bylo od razu bezposrednio z tego obiektu odczytac dane, np: $db->fetchAllRows(); jak rowniez aby ta metoda zwraca obiekt klasy Statement z ktorego mozna byloby te dane odczytac pozniej:
$s = $db->execute(); $s->fetAllRows();
Majac statement tez mozesz wywolac fetchAll.
Stworzyles klase Statement ktora nie robi nic innego jak jest posrednikiem do wywolania fetch() Kody sprawdzajace ktore sa w tych funkcjach w twojej klasie jak juz pisalem nie maja zadnego sensu
Na szczescie niedlugo majowka, bedzie czas zeby to przepisac.
Tylko po co przepisywać? To i tak się nie nadaje do użytku choćby dlatego że wpływasz na wyjątki. A projektów dużo lepiej napisanych jest pełno. Chyba że chcesz się czegoś nauczyć to ok.
Zwracanie dwóch różnych typów w jednej metodzie jest złe. Od tego są wyjątki, aby je wyrzucać, kiedy funkcja nie potrafi zwrócić typu wartości, do którego została stworzona.
albo zwrócić pusty array jeśli zwracamy array. Choć exception jest lepszym pomysłem.
Tutaj akurat bym się kłócił. Nie wiem o który przykład Ci chodzi, ale jeżeli szukasz czegoś w bazie, to pusty array nie jest taki zły (chociaż można lepiej, obiektem-kolekcją).
@mrc kolegom chodzilo raczej nie o brak danych a o blad pobierania danych
Wrzuć to na jakiegoś githuba i podstawowe pytanie jaki to ma cel?
hobbystyczno-edukacyjny
v2: http://wklej.org/hash/6c51b2aeb3d/
A tak przy okazji. Wiesz że możesz dalej rzucić ten wyjątek?
catch (PDOException $e) {
throw $e;
}
if(!isset($this->pdo)) {
daj poprostu
if(!$this->pdo) {
if(!$this->stmt instanceof \PDOStatement) {
Nigdzie z zewnatrz nie ustawiasz stmt wiec albo t bedzie PDOStatement albo nic. Daj poprostu
if(!$this->stmt) {
No i jesli nie ma stmt to powinien leciec wyjatek a nie pusta tablica. Skoro ktos robi fetchAll a wczesniej nie zrobil execute to jest to blad
Gdy juz zamienisz to wyjatki to takie kody jak ten
if(!$this->stmt instanceof \PDOStatement) {
return false;
}
maja byc w oddzielnej funkcji i tylko wywolujesz te funkcje ktora rzuci wyjatkiem. nie ma sensu wszedzie duplikowac takich kodow
ta funkcja
public function isConnected() { $this->clearError(); if(!$this->pdo instanceof \PDO) { $this->setError('08003', 'SQLSTATE[08003] Connection does not exist'); return false; } return true; }
public function isConnected() { $this->clearError(); return $this->pdo ? true: false; }
Przy okazji mam 1 pytanie niezwiazane do konca z tematem.
Mianowicie IDE wskazuje mi blad method not found w liniach w ktorych wywoluje jakas metode z PDO, np $this->pdo->commit();
Mozna to jakos obejsc? Powiedziec IDE ze tam jest PDO, jezeli w innej metodzie wykonuje $this->pdo = new \PDO() ?
Dodaj komentarz do property z typem PDO.
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)