Korte OOP vragen
ik ben nu reeds een aantal weken bezig met OOP PHP en moet zeggen dat het me zeer bevalt. Echter heb ik een vraag. Is het mogelijk om de standaard functies in PHP bv: de mysql_error() en de mysql_real_escape_string() te verkleinen. Als je het niet snapt, ik bedoel zo iets als dit:
$this->error ipv mysql_error();
$this->escape->$_POST['value'] ipv mysql_real_escape_string;
Is dit mogelijk? Zo ja is het efficiënter om het dan zo te doen of gewoon de standaard aanhouden?
Alvast bedankt,
Michiel
$this werkt alleen binnen een enkel object. Als je dus de volgende klasse hebt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class Database
{
$handler;
public function __construct($host, $username, $password, $dbname)
{
$this->handler = pg_connect(sprintf("host=%s dbname=% user=% password=%", $host, $username, $password, $dbname);
if(!$this->handler)
throw new Exception('Kan geen verbinding maken');
}
public function query($query)
{
return new DatabaseResult(pg_query($this->handler, $query));
}
}
{
$handler;
public function __construct($host, $username, $password, $dbname)
{
$this->handler = pg_connect(sprintf("host=%s dbname=% user=% password=%", $host, $username, $password, $dbname);
if(!$this->handler)
throw new Exception('Kan geen verbinding maken');
}
public function query($query)
{
return new DatabaseResult(pg_query($this->handler, $query));
}
}
Je ziet nu steeds $this terugkomen als er een waarde uit de klasse wordt aangeroepen. Als ik dan alleen een andere klasse heb, kan ik niet opeens $this->handler doen. Wat ik wel kan doen is het volgende:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
class UserMapper
{
private $db;
public function __construct(Database $db)
{
$this->db = $db;
}
public function getUsers()
{
$result = $this->db->query("SELECT * FROM users;");
$result->fetchAll();
}
}
{
private $db;
public function __construct(Database $db)
{
$this->db = $db;
}
public function getUsers()
{
$result = $this->db->query("SELECT * FROM users;");
$result->fetchAll();
}
}
Zie ook dit artikel:
https://webdevils.nl/articles/4-relaties-in-object-ge-rienteerd-programmeren/
Overigens is het wel af te raden om nog gebruik te maken van mysql_*, want ik hoor steeds vaker dat deze niet meer ondersteund zal worden in volgende versies van PHP. Kijk dus ook eens naar MySQLi.
- Werken met verschillende db types (bijv. SQLite)
- Werken met prepared statements (dan heb je geen mysql_real_escape_string meer nodig)
- Class style, waardoor het overzichtelijker is in OOP
- Transacties
- ...
En nog een ander punt waarom je over zou stappen op PDO of MySQLi: PHP6 gaat de standaard mysql_* functies niet meer als standaard aannemen, deze staan dan standaard uit.
Gewijzigd op 01/04/2011 16:17:32 door Wouter J
Wouter J op 01/04/2011 16:17:19:
(...)
En nog een ander punt waarom je over zou stappen op PDO of MySQLi: PHP6 gaat de standaard mysql_* functies niet meer als standaard aannemen, deze staan dan standaard uit.
En nog een ander punt waarom je over zou stappen op PDO of MySQLi: PHP6 gaat de standaard mysql_* functies niet meer als standaard aannemen, deze staan dan standaard uit.
Dit is niet waar. Mysql wordt gewoon nog in principe ondersteund in php versie zes. Maar ja, ze doen nu al zo lang over die nieuwe versie dat je eigenlijk niet op aan kan wat wel en niet komt. Door verschillende mensen zijn ook bijvoorbeeld verkeerde dingen verspreid (dat mysql verwijderd wordt).
Mysql wordt té veel gebruikt om hem zomaar eruit te slopen. Ook blijft die gewoon nog aanstaan.
Verder heeft mysqli soms geintjes die je liever niet wilt hebben, dat je opeens een query niet mag uitvoeren enzo. PDO is veel stabieler.
Verder is volgens mij dat jij je functies wilt chainen. Je moet dan gewoon return $this doen. Let wel op dat dit soms niet echt geheel nette OOP situaties oplevert.
Wouter J op 01/04/2011 16:17:19:
Ik zou voor PDO gaan i.p.v. MySQLi. Wat PDO voor anders bied te opzichte van MySQL:
- Werken met verschillende db types (bijv. SQLite)
- Werken met prepared statements (dan heb je geen mysql_real_escape_string meer nodig)
- Class style, waardoor het overzichtelijker is in OOP
- Transacties
- Werken met verschillende db types (bijv. SQLite)
- Werken met prepared statements (dan heb je geen mysql_real_escape_string meer nodig)
- Class style, waardoor het overzichtelijker is in OOP
- Transacties
Ik zal dit even punt voor punt ontkrachten:
1. Wat heb je eraan dat je meerdere database typen hebt. Hoe vaak wissel jij van database in je applicatie? Ik heb dat nog maar zelden meegemaakt en dan biedt PDO echt geen uitkomst, je zal namelijk nog steeds (bijna) al je queries aan moeten passen. Zeker als je van of naar MySQL wil migreren.
2. Prepared statements kunnen ook gewoon in MySQLi. Is een functionaliteit van je database, niet je library. Daarnaast zijn prepared statements vooral handig als je veel dezelfde select queries uit wil voeren met alleen een paar WHERE parameters anders. De database kan dan het query plan onthouden. SQL injection los je er nog niet 100% mee op, want het komt vaak genoeg voor dat er nog delen van een query gegenereerd worden door je applicatie en dat kan niet met prepared statements
3. MySQLi kan ook gewoon in klassen. Daarnaast kan je natuurlijk ook gewoon zelf de methoden in een klasse gieten. Als laatste, waarom zou je altijd OOP gebruiken, niets mis met functioneel of procedureel programmeren.
4. Idem als voor 2. Het is een functionaliteit van je database. Je kan dat met elke library waarmee je queries uit kan voeren gewoon doen. Daarbij zijn er zover ik weet ook in MySQLi speciale methdoen om transactions te starten, te committen en te rollbacken.
5. Ga verder :)
Quote:
En nog een ander punt waarom je over zou stappen op PDO of MySQLi: PHP6 gaat de standaard mysql_* functies niet meer als standaard aannemen, deze staan dan standaard uit.
Het idee is dat de licensies voor de MySQL library niet bij PHP liggen, maar bij een derde partij. Het wordt dan ook niet meer standaard meegeleverd bij volgende PHP versies, want overigens niet inhoud dat je het niet meer kan gebruiken. De library is nog steeds te downloaden en te activeren. Iets wat veel hosting partijen wel zullen doen, als je überhaubt nog bij shared hosting zit en niet gewoon VPS draait.
Daarnaast heb ik pas ergens begrepen dat PHP 6 helemaal niet meer komt.
Quote:
Als laatste, waarom zou je altijd OOP gebruiken, niets mis met functioneel of procedureel programmeren.
Programmeren hoort in grote systemen naar mijn mening gewoon OOP te zijn.
In de meeste programmeer talen kan je niet eens procedureel programmeren.
Mark Kazemier op 02/04/2011 15:36:44:
Ik zal dit even punt voor punt ontkrachten:
1. Wat heb je eraan dat je meerdere database typen hebt. Hoe vaak wissel jij van database in je applicatie? Ik heb dat nog maar zelden meegemaakt en dan biedt PDO echt geen uitkomst, je zal namelijk nog steeds (bijna) al je queries aan moeten passen. Zeker als je van of naar MySQL wil migreren.
Wouter J op 01/04/2011 16:17:19:
Ik zou voor PDO gaan i.p.v. MySQLi. Wat PDO voor anders bied te opzichte van MySQL:
- Werken met verschillende db types (bijv. SQLite)
- Werken met prepared statements (dan heb je geen mysql_real_escape_string meer nodig)
- Class style, waardoor het overzichtelijker is in OOP
- Transacties
- Werken met verschillende db types (bijv. SQLite)
- Werken met prepared statements (dan heb je geen mysql_real_escape_string meer nodig)
- Class style, waardoor het overzichtelijker is in OOP
- Transacties
Ik zal dit even punt voor punt ontkrachten:
1. Wat heb je eraan dat je meerdere database typen hebt. Hoe vaak wissel jij van database in je applicatie? Ik heb dat nog maar zelden meegemaakt en dan biedt PDO echt geen uitkomst, je zal namelijk nog steeds (bijna) al je queries aan moeten passen. Zeker als je van of naar MySQL wil migreren.
Tenzij je natuurlijk iets wilt als bijvoorbeeld doctrine, dan is het toch wel makkelijk.
Als je weet wat de verschillen zijn tussen de verschillende engines dan is het geen probleem. Dan kan je veel beter pdo pakken. Onder andere omdat je dan dus veel beter OOP kan schrijven, want je kunt gewoon PDO klasses extenden e.d.
Mark Kazemier op 02/04/2011 15:36:44:
2. Prepared statements kunnen ook gewoon in MySQLi. Is een functionaliteit van je database, niet je library. Daarnaast zijn prepared statements vooral handig als je veel dezelfde select queries uit wil voeren met alleen een paar WHERE parameters anders. De database kan dan het query plan onthouden. SQL injection los je er nog niet 100% mee op, want het komt vaak genoeg voor dat er nog delen van een query gegenereerd worden door je applicatie en dat kan niet met prepared statements
Prepared statements met pdo is wel handiger dan met mysqli, pdo kan ook named prepared statements, wat niet met mysqli kan. Dynamisch gegenereerde queries hebben hier niks mee te maken. Als die verkeerd worden gemaakt, zullen ze ook gewoon bij mysql_* en PDO problemen opleveren.
Mark Kazemier op 02/04/2011 15:36:44:
3. MySQLi kan ook gewoon in klassen. Daarnaast kan je natuurlijk ook gewoon zelf de methoden in een klasse gieten. Als laatste, waarom zou je altijd OOP gebruiken, niets mis met functioneel of procedureel programmeren.
Kies dan wel het één of het ander. Functioneel en OOP door elkaar doen is niet handig, gebruik dan als je functioneel programmeert ook geen klasses zoals mysqli.
Zie ook eens andere vergelijkingen: mysqli vs pdo.
Mark Kazemier op 02/04/2011 15:36:44:
Het idee is dat de licensies voor de MySQL library niet bij PHP liggen, maar bij een derde partij. Het wordt dan ook niet meer standaard meegeleverd bij volgende PHP versies, want overigens niet inhoud dat je het niet meer kan gebruiken. De library is nog steeds te downloaden en te activeren. Iets wat veel hosting partijen wel zullen doen, als je überhaubt nog bij shared hosting zit en niet gewoon VPS draait.
Daarnaast heb ik pas ergens begrepen dat PHP 6 helemaal niet meer komt.
Quote:
En nog een ander punt waarom je over zou stappen op PDO of MySQLi: PHP6 gaat de standaard mysql_* functies niet meer als standaard aannemen, deze staan dan standaard uit.
Het idee is dat de licensies voor de MySQL library niet bij PHP liggen, maar bij een derde partij. Het wordt dan ook niet meer standaard meegeleverd bij volgende PHP versies, want overigens niet inhoud dat je het niet meer kan gebruiken. De library is nog steeds te downloaden en te activeren. Iets wat veel hosting partijen wel zullen doen, als je überhaubt nog bij shared hosting zit en niet gewoon VPS draait.
Daarnaast heb ik pas ergens begrepen dat PHP 6 helemaal niet meer komt.
Inderdaad komt er een andere versie van mysql in de plaats. Namelijk mysqlng. Deze zal nog gewoon te gebruiken zijn, later wordt mysql afgeschaft.
Verder is het natuurlijk de vraag wanneer php6 uitkomt. Veel dingen die in php6 zouden komen zijn al in php5.3 ingevoerd. Jammer genoeg zijn de dingen zoals verbeterde i18n en L10n support nog niet geïmplementeerd, die dus wel in php6 zouden komen. Daarom verwacht ik dat php6 in een of andere vorm nog wel uit zal komen, deze is speciaal gericht op betere ondersteuning van i18n en L10n.
Quote:
Tenzij je natuurlijk iets wilt als bijvoorbeeld doctrine, dan is het toch wel makkelijk.
Als je weet wat de verschillen zijn tussen de verschillende engines dan is het geen probleem. Dan kan je veel beter pdo pakken. Onder andere omdat je dan dus veel beter OOP kan schrijven, want je kunt gewoon PDO klasses extenden e.d.
Als je weet wat de verschillen zijn tussen de verschillende engines dan is het geen probleem. Dan kan je veel beter pdo pakken. Onder andere omdat je dan dus veel beter OOP kan schrijven, want je kunt gewoon PDO klasses extenden e.d.
Doctrine eist dat je PDO gebruikt. Wat verder niet wil zeggen dat je het zelf ook moet gebruiken. Daarnaast krijg je met ORM nog vele extra problemen. Zoals dat je geen controle meer hebt over de queries die je uitvoert. Daarbij kan je dan geen database specifieke dingen meer uitvoeren wat dus direct de kracht van je database weghaalt. En als laatste, als je ingewikkelde dingen moet doen, moet je er omheen omdat dat gewoonweg niet werkt. Oftewel een echte no-go.
Daarnaast kan je PDO gebruiken, maar je kan natuurlijk ook je eigen database klassen gebruiken. Heeft voor OOP weinig verschil. Persoonlijk gebruik ik PDO omdat ik geen zin heb om het wiel opnieuw uit te vinden.
Quote:
repared statements met pdo is wel handiger dan met mysqli, pdo kan ook named prepared statements, wat niet met mysqli kan. Dynamisch gegenereerde queries hebben hier niks mee te maken. Als die verkeerd worden gemaakt, zullen ze ook gewoon bij mysql_* en PDO problemen opleveren.
Ten eerste, prepared statements kan je met elke library maken die het mogelijk maakt om queries uit te voeren. Het is namelijk een feature van je database. Dus alles dat je betreft prepared statements kan, kan in beide libraries. Of MySQLi en mysql_* het moilijker maken, weet ik niet. Ik gebruik geen MySQL.
Dat tweede punt is dus precies wat jouw argument ontkracht. Het maakt niet uit of je PDO of mysql_* gebruikt, in beide gevallen heb je problemen.
Quote:
Kies dan wel het één of het ander. Functioneel en OOP door elkaar doen is niet handig, gebruik dan als je functioneel programmeert ook geen klasses zoals mysqli.
Kies dan wel het één of het ander. Functioneel en OOP door elkaar doen is niet handig, gebruik dan als je functioneel programmeert ook geen klasses zoals mysqli.
MySQLi biedt je de mogelijkheid om te kiezen. Je kan zowel OOP als procedureel mee programmeren.
Quote:
Programmeren hoort in grote systemen naar mijn mening gewoon OOP te zijn.
In de meeste programmeer talen kan je niet eens procedureel programmeren.
In de meeste programmeer talen kan je niet eens procedureel programmeren.
Ik zie graag argumenten die dit onderbouwen... De tweede statement is sowieso bullshit.