Jedną z lepszych rzeczy w CakePHP jest możliwość pobierania danych z bazy przy pomocy modeli, np.

$this->Tabela->field("name");

a gdybym chciał to zrobić tak:

tabela::get(); albo: tabela::get_field("name");

jeśli stworzę klasę:

class tabela extends db{
}

a potem dodam w/w metody do klasy obsługującej zapytania sql:

class db extends core{

public static function get(....)

}


Wszystko fajnie, nazwę tabeli uzyskam dzięki get_called_class. I już wszystko śmiga. Z jednym "ALE"


Modele trzeba tworzyć ręcznie.

Za każdym razem muszę deklarować:

class Jakaśtam extends db{

}

class Inna extends db{
}

... (i tak dalej, do przysłowiowej usranej...)


A gdybym chciał to zrobić hurtowo? Na przykład, utworzyć po jednej klasie do każdej tabeli z mojej bazy danych.

(pomijam stosowanie eval'a)

da się?


albo gdybym zapodał tablicę z klasami do utworzenia ("users", "articles", "pages")

jak utworzyć te klasy hurtowo, bez evala?

Możesz przechwytywać takie rzeczy __autoload, parsować nazwę po czym tworzyć sobie obiekty dziedziczące po klasie abstrakcyjnej, którą sobie stworzysz.

Takie rzeczy rozwiązuje się za pomocą generatorów kodu. Opisujesz sobie strukturę w jakimś formacie i generujesz z niej zarówno zapytania SQL, jak i szkielety klas, albo parsujesz strukturę bazy i generujesz dla niej szkielety klas, które później wypełniasz. Alternatywny pomysł to zaprojektowanie tego w sposób obiektowy (bo tego, co tu powypisywałeś, nie da się nazwać obiektowością). Masz obiekt klasy Table, który przechowuje sobie jako pole nazwę oraz pola, a jego metody na podstawie argumentów potrafią wybrać wszystko, co potrzeba. Wtedy tabele reprezentowane będą przez obiekty i chyba to jest idea kryjąca się za mechanizmem w Cake'u PHP. Przepisanie tego na metody statyczne to jedna z głupszych rzeczy, jakie można zrobić, gdyż równa się to de facto przejściu na zwykłe programowanie strukturalne z utratą wszystkich zalet obiektówki. Patrząc na Twoje inne tematy widzę, że zafascynowały Cię pola i metody statyczne. Radziłbym Ci z tą fascynacją zerwać, gdyż w zdecydowanej większości przypadków nie są one nikomu do niczego potrzebne, a ty ich po prostu nadużywasz nie wiedząc nawet, po co Ci to.

Już tak na marginesie dodam, że nazywać to "modelami" to tak, jakby mówić na chleb "zupa". To jest maper obiektowo-relacyjny, a nie żaden model.

Zyx.

mam wrażenie, że wiele systemów nadużywa wygód, jakie dają funkcje public static,

np. Fat Free php framework, czy (miejscami!) kohana

Taka metoda ma tą zaletę, że nie trzeba deklarować nowych funkcji, typu $sanitize=new sanitize();

i upraszczają zapis, w moim przypadku:

$this->db->get("name")

db::get("name");




Masz jednak rację, to nie jest w pełni programowanie obiektowe, jednak znacznie upraszcza kodowanie.

To nie jest w ogóle programowanie obiektowe. Samo korzystanie z mechanizmu klas nie czyni jeszcze kodu obiektowym. Kodowania też specjalnie to nie upraszcza, zwłaszcza gdy będziesz miał dużo zależności między komponentami, które są zaszyte na sztywno w kodzie. Przekonasz się, gdy będziesz musiał taki system zmodyfikować lub przetestować i się w nim pogubisz, albo trafi Cię szlag z powodu mnóstwa magicznych zachowań. Nie bez powodu nawet w językach, w których nie ma obiektówki, interfejsy programistyczne projektuje się na wzór programowania obiektowego, tyle że przy pomocy struktur, funkcji i wskaźników do tychże.

Zainteresuj się Doctrine, niedawno wyszła stabilna 2.