Discussion :

[alucardalex]

Bonjour,

Je réalise actuellement une DAL en PHP qui doit générer les requêtes SQL à la volée : l'objectif et de ne plus écrire de requêtes SQL. Le but est que les modèles utilisent la DAL pour exécuter des requêtes SQL en lui passant toutes les informations nécessaires (ex: la table, la liste des champs, les valeurs et les conditions pour un update). La DAL utilisera pdo pour exécuter les requêtes et renverra les données aux modèles.

Voici une ébauche du diagramme de classes de la DAL (les paramètres des méthodes sont absents pour le moment):



Pourriez-vous me donner votre avis sur ce choix technique, sur cette ébauche de DAL et me transmettre vos retours d'expérience sur cette implémentation.

Merci beaucoup.

[rawsrc]

Bonjour,

je pense que tu es encore loin du compte.
Tu dois ajouter la gestion des autres clauses : ORDER BY, GROUP BY, HAVING, LIMIT. Ensuite prévoir la validation automatique des données, la gestion des type de données incompatibles avec PDO, le formatage et l'échappement automatique de toutes les données, laisser la possibilité d'utiliser des sous-requêtes dont la construction doit pouvoir être automatisée comme une requête standard et enfin rendre cet outil compatible avec d'autre moteurs que mysql (sans avoir à tout te retaper).
Bref, bon courage.
Je te dis ça parce que je me suis déjà coltiné tout ça et crois-moi, tu vas sacrément phosphorer si tu ne veux pas faire une énorme usine à gaz (avec de perfs toutes nazes).
Si t'es étudiant, un projet comme celui-là va te remplir l'année entière

[grunk]

Un bon projet duquel tu pourrais certainement tirer des choses intéressantes :
https://github.com/j4mie/idiorm
et son extension :
https://github.com/j4mie/paris

Le tout tient en 2 fichiers et est plutôt simple à comprendre.

[alucardalex]

Bonjour,

effectivement il manque des fonctionnalités, surtout pour les select.
La validation des données n'est-elle pas dévolue au contrôleur qui sera dans la couche MVC "au dessus" de cette DAL ?

Le but de la démarche est d'obtenir une DAL simple et performante en CRUD que l'on puisse réutiliser pour tous nos sites mais on ne veut pas utiliser un ORM pour :
*éviter toutes les opérations de configuration
*être perdant en terme de performances
et que l'on surchargera suivant les spécificités du site et surtout pour les back office.

Merci pour vos retours.

[grunk]

La validation des données n'est-elle pas dévolue au contrôleur qui sera dans la couche MVC "au dessus" de cette DAL ?

La validation des données oui. Il faudra cependant dans ta DAL implémenter les sécurités d'usage (requête préparé par exemple).
Après si le développeur laisse passer des données à risque c'est à priori pas ton problème.

Même si tu ne veux pas d'ORM jete un oeil aux liens que je t'ai donné. La seile config à faire est la même que celle de PDO après ça marche tout seul . On est à des années lumière des doctrine ou propel.

[rawsrc]

La validation des données n'est-elle pas dévolue au contrôleur qui sera dans la couche MVC "au dessus" de cette DAL ?

Tout dépend de la manière dont tu perçois cette couche.
Si c'est dans l'optique de rester simple, c'est bien le contrôleur qui devra connaitre les contraintes d'accès aux données et c'est encore lui qui devra valider ces même données.
Par contre si tu la considères comme un service ou une ressource, le contrôleur ne dispose que d'une liste de ressources qu'il peut utiliser et paramétrer mais la cuisine interne lui est inconnue, en conséquence il ne sait pas comment valider et selon quelles contraintes. Il doit donc se fier au service qui fait sa vie dans son coin. Il faut dans ce cas prévoir un mécanisme qui te remonte à la surface les erreurs pour chaque variable ayant échoué un test "quelque part" au sein du service.
La deuxième option est plus complexe mais de loin la plus souple et la plus portable vu que tu ne mélanges pas les données avec le contrôleur.

[grunk]

La deuxième option est plus complexe mais de loin la plus souple et la plus portable vu que tu ne mélanges pas les données avec le contrôleur.

Le controller fait le lien entre le modèle et la vue donc forcément il va manipuler les données à un moment donné.

Perso je vois pas comment sur une DAL tu peux prendre en compte tous les cas possible et imaginable de validation des données. C'est juste pas possible. Donc autant ne rien faire et laisser cette tache au développeur

[rawsrc]

@grunk
Ce que je voulais dire, c'est qu'il est tout à fait possible de créer des ressources data spécifiques à chaque besoin et de déporter le plus gros du travail de validation, formatage des données en dehors du contrôleur.
Le point principal c'est que le contrôleur sache toujours quelle porte d'entrée du modèle ouvrir mais après le modèle fait à peu près ce qu'il a envi en fonction de ses besoins. Le contrôleur lui ne gère que l'orchestration des retours des différents appels nécessaires au déroulement d'une tâche.
Je ne sais pas si je suis très clair

[alucardalex]

Bonjour,

Concernant les contrôles les deux remarques me semblent très justes :

*le contrôleur fera les contrôles sur les données saisies (tout du moins si on interprète la couche MVC de cette manière)

*si on perçoit la DAL comme une boite noire (type web service) il évident quelle doit réaliser un minimum de contrôles sur les paramètres qui lui sont passés. Cela lui permettra aussi d'être beaucoup plus adaptable à différents projets de part la perte de dépendance au contrôleur.

Dans cette vision à double contrôles :

*les données sont saisies dans la vue et postées vers le contrôleur
*le contrôleur teste les données
*si elles sont OK il instancie le modèle
*le modèle formatte les données pour la DAL (sous forme de tableaux, par exemple : un tableau qui contient tous les champs d'un select)
*le modèle utilise la DAL pour exécuter la requête en base
*la DAL teste les paramètres et constitue la requête grâce aux paramètres, exécute la requête et renvoie les résultats au modèle
*le modèle renvoie le résultat au contrôleur
*le contrôleur traite le cas "retour de données" ou le cas "erreur" et choisi la vue adaptée

merci de me donner votre avis sur cette conception

@grunk
je teste le code que tu as donné et on en reparle