JeuWeb - Crée ton jeu par navigateur
[Framework] Avantages et inconvénients ? - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Framework] Avantages et inconvénients ? (/showthread.php?tid=2900)

Pages : 1 2 3 4 5 6 7 8


RE: [Framework] Avantages et inconvénients ? - zzarbi - 19-08-2008

oxman a écrit :Tu as un exemple de DAO pour SQL ? Finalement j'ai l'impression que c'est comme une classe d'abstraction.

Bah c'est pas compliqué

Code PHP :
<?php 
bo
/User.class.php
class User{

//Equivalent champ table
private $name;

//Getter/setter
public function setName($p_name) {
$this->name=$p_name;
}
public function
getName() {
return
$this->name;
}
}
Ce fichier doit etre le plus simpliste possible

Code PHP :
<?php 
dao
/UserDAO.class.php
class UserDAO{

//Methode d'acces aux données
public function GetUserByID($p_Id){
$requeteSQL = 'SELECT * FROM user WHERE id=\''.$p_Id.'\'';
$result = retour du résultat de la $requeteSQL en utilisant ce que du veux ;

return
LoadUser($result);
}
...


//Rempit un BO
public function LoadUser($result){
$User = new User();
$user->SetName($result['name']);
return
$User;
}

//Remplit un tableau de BO
public function LoadUsers($result){
...
}
}
Cette classe peut etre static, elle n'a pas besoin d'etre instanciable.

Voila l'exemple globale. On peut compléter cette exemple en rajoutant une couche métier, un controlleur, une couche d'execption, une couche de vue, et une couche de service.
La couche service permet de vérifier les données, avant de les envoyer au DAO, on pourrait vérifier les donnée dans les DAO ou à l'instanciation des données, mais comme vous le savez certaines données n'ont pas besoin d'être vérifier, par conséquent il est inutile de le faire, en tous cas pas logique de le faire dans les DAO/BO...

Donc pour finir, dans cette exemple on voit bien que les BO sont tout à fait générable à partir de la BDD, et les requetes simples des DAO aussi.

On peut egalement faire une classe abtraite DAO, qui implémente les requetes de bases...

Pour finir, ce code permet de séparer l'accés aux données des données sur lesquels on bosse, ça ressemble un peu à une classe d'abstraction, sauf que si on change de BDD, on a tous les DAO à refaire.
Mais dans notre classe DAO en plus des traitement SQL j'aurais pu rajouter un :
GetALLByUserXML(); qui retournera le même type de tableau d'objet bo que le SQL;

Le but est plus d'éclaircir le code, que de faire une abstraction. SI vous avez un problème avec les données vous savez que c'est dans les DAO et non pas n'importe où dans le code...


RE: [Framework] Avantages et inconvénients ? - QuentinC - 19-08-2008

Pour répondre au post de zzarbi :
Citation :Tu vas pas me dire qu'à chaque projet tes requêtes SQL Changent...
Ben si : select * from users, c'est pas pareil que select * from articles. La syntaxe SQL est la même, mais les données ne sont pas traités de la même façon. ON ne fait pas la même chose avec.

Citation :Mais voila smarty par exemple apporte la gestion du cache, et d'autre outils plutôt intéressant que tu ne pourra pas faire en PHP sans apporter du code.
Faire un système de cache, c'est pas ce qu'il y a de plus difficile à faire. fil_exists, filemtime, file_Get_contents, l'output buffering et la sérialisation si besoin, et basta.

Merci pour l'explication et le lien sur les DAO, c'est vrai que ça pourrait me servir. Parce que jusqu'à maintneant, j'ai toujours fait à peu près ça quand je fais de l'OO en php :
Code :
<?php
class User {
private __construct ($data) {
foreach ($data as $key=>$value) {
$this->$key=$value;
}}
public function updateToDb () {
$sql = '';
foreach ($this as $key=>$value) {
if (!is_string($value) && !is_int($value) && !is_float($value)) continue;
$sql .= ($sql? ', ':'') ."$key='$value'";
}
mysql("update users set $sql where id = {$this->id}");
}
// ...
public static function getByPseudo ($pseudo) {
$pseudo = mysqlEscape($pseudo);
$data = mysqlRow("select * from users where pseudo = '$pseudo'");
return new User($data);
}
public static function getById ($id) {
// ...
}
// ...
}
?>
Ca me saoule d'écrire 30 getters et 30 setters... c'est dommage que php ne peut pas remplir les variables d'insstances vers sql et vice-versa, mais ton truc pourrait m'être utile, on ne sait jamais.


RE: [Framework] Avantages et inconvénients ? - zzarbi - 19-08-2008

QuentinC a écrit :Ben si : select * from users, c'est pas pareil que select * from articles. La syntaxe SQL est la même, mais les données ne sont pas traités de la même façon. ON ne fait pas la même chose avec.
Oui oui j'ai pas dis le contraire, mais je parle bien de générer la syntaxe de la requete...
Le but de mon "générateur" c'est d'écrire mes classes avec les syntaxes de bases du sql.

En gros (Vraiment en gros, sans utilisation de DAO) si j'ai 2 tables users et articles, il me fera 2 fichiers :
Code PHP :
<?php 
users
.php
class users{
public function
GetUsers(){
$requete = 'select * from users';
//execute requete
return $resultat;
}
}

Code PHP :
<?php 
articles
.php
class articles{
public function
GetArticles(){
$requete = 'select * from articles';
//execute requete
return $resultat;
}
}
(J'ai fait que la méthode getObject() ^^)

Les fichiers sont strictement identiques à part le nom des classes/methodes/tables ! Si j'ai 20 tables ça m'évite de me taper tous les getter/setter à la main, et toute les requetes basiques qui sont strictement les mêmes si on oublie le nom des champs/tables...

On pourrait aussi faire une classe générique qui génèrerais la requete sql à la voléé, mais du coups à chaque requetes il devra la construire. Ce qui entrainerait une perte légère de performance.

Si on pense ensuite aux DAO, il me gènèrent alors 2 fichiers par table, un avec des getters/setters, et l'autre avec les requetes basique SQL...


Tout le traitement que tu feras avec les resultats retourné eux resteront complètement différents...



QuentinC a écrit :Faire un système de cache, c'est pas ce qu'il y a de plus difficile à faire. fil_exists, filemtime, file_Get_contents, l'output buffering et la sérialisation si besoin, et basta.
Faut quand même le coder ^^, mais je concoit que faire une surcouche ici ne sert à rien.

QuentinC a écrit :Merci pour l'explication et le lien sur les DAO, c'est vrai que ça pourrait me servir. Parce que jusqu'à maintneant, j'ai toujours fait à peu près ça quand je fais de l'OO en php :
Code PHP :
<?php
class User {
private
__construct ($data) {
foreach (
$data as $key=>$value) {
$this->$key=$value;
}}
public function
updateToDb () {
$sql = '';
foreach (
$this as $key=>$value) {
if (!
is_string($value) && !is_int($value) && !is_float($value)) continue;
$sql .= ($sql? ', ':'') ."$key='$value'";
}
mysql("update users set $sql where id = {$this->id}");
}
// ...
public static function getByPseudo ($pseudo) {
$pseudo = mysqlEscape($pseudo);
$data = mysqlRow("select * from users where pseudo = '$pseudo'");
return new
User($data);
}
public static function
getById ($id) {
// ...
}
// ...
}
?>
Oui et les DAO sont surtout utilisé en Réseau, car si on envoit un flux de donné on préfère envoyer juste un Objet avec des getter/setter (un BO) qu'un Objet plus complexe avec toutes ses méthodes SQL qui prendra plus de place en donnée pure (Enfin ca depend comment on le serialize)...

QuentinC a écrit :Ca me saoule d'écrire 30 getters et 30 setters... c'est dommage que php ne peut pas remplir les variables d'insstances vers sql et vice-versa, mais ton truc pourrait m'être utile, on ne sait jamais.
D'où l'utilité de mon "générateur" ^^


RE: [Framework] Avantages et inconvénients ? - QuentinC - 19-08-2008

Ahaahaha, je viens de capter un truc. En fait tu utilises php pour générer du php. J'avais pas compris ça...
ET effectivement, là, ça devient intéressant. Tu as une vraie classe avec des vrais getter et des vrais setter, l'encapsulation tout ça ...
l'étape suivante c'est qu'à partir d'une instruction create table, il crée une classe php basique... ahhaha.... j'ai comme une ampoule qui vient de s'allumer en moi là. J'avais vraiment pas compris que tu générais du php ... avec du php.

Par contre je suis toujours éteint sur à quoi sert un contrôleur sous forme de classe. Par définition un contrôleur pour moi c'est une série d'actions, du procédural quoi.


RE: [Framework] Avantages et inconvénients ? - Ter Rowan - 19-08-2008

QuentinC a écrit :Ahaahaha, je viens de capter un truc. En fait tu utilises php pour générer du php. J'avais pas compris ça...
ET effectivement, là, ça devient intéressant. Tu as une vraie classe avec des vrais getter et des vrais setter, l'encapsulation tout ça ...
l'étape suivante c'est qu'à partir d'une instruction create table, il crée une classe php basique... ahhaha.... j'ai comme une ampoule qui vient de s'allumer en moi là. J'avais vraiment pas compris que tu générais du php ... avec du php.

Par contre je suis toujours éteint sur à quoi sert un contrôleur sous forme de classe. Par définition un contrôleur pour moi c'est une série d'actions, du procédural quoi.


hummm merci Quentin, tu viens de m'éclairer ^^


RE: [Framework] Avantages et inconvénients ? - QuentinC - 19-08-2008

Citation :hummm merci Quentin, tu viens de m'éclairer
C'est de l'humour juste pour en rajouter une couche ou bien c'est sincère ?


RE: [Framework] Avantages et inconvénients ? - Ter Rowan - 19-08-2008

QuentinC a écrit :
Citation :hummm merci Quentin, tu viens de m'éclairer
C'est de l'humour juste pour en rajouter une couche ou bien c'est sincère ?

non pareil que toi,même situation, même réflexion ^^


RE: [Framework] Avantages et inconvénients ? - zzarbi - 20-08-2008

oxman a écrit :Je veux un exemple SQL, ça n'en est pas un ça.

Ah l'exemple d'un DAO. Bah ca depend de beaucoup de chose...
De comment tu veux te connecter à mysql par exemple...


RE: [Framework] Avantages et inconvénients ? - QuentinC - 20-08-2008

Je viens de découvrir PDO. C'est pas une sorde de DAO ça ?

Avec ce qu'on apprend sur ce topic, une fois de plus j'ai envie de tout recommencer parce que mon truc est de la merde.
Cette fois c'est décidé, je me mets à la POO php... enfin je vais essayer... PDO a l'air sympa.


RE: [Framework] Avantages et inconvénients ? - zzarbi - 20-08-2008

PDO est juste une classe d'abstraction qui te permet de changer de base de donnée sans changer bcp de une ligne de code...
Mais de 1 c'est faux (Certaines requetes, ne fonctionne pas entre les différent serveur SQL, suffit de regarder mysql 4 et mysql 5...)
et de 2 on change rarement voir jamais de base de donnée (en tous cas pas sans changer de technologie dans mon cas)

Un petit lien vers la doc FR de l'extension PDO : http://fr2.php.net/manual/fr/intro.pdo.php

Donc, en gros dans ton code tu fais un truc du genre :

Code PHP :
<?php
$dbh
= new PDO('mysql:host=localhost;dbname=test', $user, $pass);

$dbh->query('Select * FROM bidule;');
?>

Et si tu veux changer de BDD suffit de changer la chaine de connection par un truc du genre :
'mssql:host=localhost;dbname=test' pour microsoft SQL server... (pas besoin de changer l'appel à la méthode query()...)
Donc si ton appli est bien architecturé, t'as juste une chaine à changé.

Mais comme je le dis plus haut implicitement, le langage SQL a été "modifié" par les personnes qui les implémentent, c'est un peu comme les différentes versions d'HTML strict/oupas.

Oracle et pgsql sont plus stricte que MySQL, donc toute les requetes de jointures peuvent ne pas fonctionner si tu changes de base.



Pour terminer, non ce n'est pas un DAO, mais tu peux l'utiliser avec un DAO. Comme tu pourrais utiliser Mysqli ou Mysql.(Avec le pattern singleton ^^)