Framework maison - Où placer la connexion à la base de données

[popayan]

J'étais parti sur la piste de la DB dans le modèle :

une classe abstraite ModeleDB avec tout ce qui est "technique" et une classe Modele qui hérite de l'autre avec tout ce qui est plus "métier". C'est ce que tu pensais?

[Viciousity]

Ouais exactement

Du coup, tu évites de répéter du code dans tes modèles métier ^^

[Arius Vistoon]

ben on est d'accord :cogne:

[Viciousity]

Excuse, j'avais mal compris ta reponse Arth'

[Hideaki]

Je n'aime pas vos approches, vous tentez de recréer l'architecture 3-tiers séparations des couches : manipulation de la BDD, métier ou service et enfin web (bien connu dans l'écosystème java et il me semble que symphonie travaille aussi de cette manière), tout en apportant les contraintes que cette architecture a éliminé comme l'indépendance des couches, un exemple concret est que cette méthode, contraint la personne qui souhaite ( même si pour l'instant, tu es le seul utilisateur ) intégrer ton framework alors que son projet est déjà fini.
Un autre inconvénient, s'il s'agit bien de la connexion à ta BDD, à chaque fois que tu hériteras de ta classe abstraite, il existera n objets ayant chaqu'un une connexion à ta BDD soit n connexions, je ne crois pas que cela est le plus efficace, à moins que tu ailles déjà paré à cela mais je doute que la méthode usée soit optimum.

Pour appliquer ces principes, tu crées un classe (singleton), l'objet ainsi créé et unique sera injecté dans ta couche Dao celle-ci manipulera les objets DAO, la partie métier ne doit pas insérer directement en base, elle doit simplement vérifier et mettre en forme les objets d'un point de vue métier uniquement

[Arius Vistoon]

tu crées un classe (singleton),

j'en avais parlé

[Hideaki]

J'ai lu de nouveau et je n'ai rien trouvé hormis cela (voir ci-dessous)

si tu as un "modèle" c'est la (et pas ailleurs) que tu le fais, et pour etre plus précis dans une classe abstraite avec le bon design pattern qui va bien, et implémenter par toutes les autres

ou

Par contre, le type de connection et le type de base de donnée doit etre comme tu le fait dans un fichier de config a part

Un design pattern c'est un terme vaste et un fichier commun ne signifie pas qu'un singleton soit utilisé

[Arius Vistoon]

j'ai dit le design pattern qui va bien, sans plus de précision car le singleton n'est pas le seul qui soit justifié dans le modele (je dirais même, c'est loin d'etre le seul qui soit adapté..bien qu'a mon sens obligatoire, les autres étant des compléments..dont certain indispensable..notemment le design pattern lié aux membres -j'ai oublie le nom- qui "force" a structurer son modele dans une architecture objet qui repond a quasi tous les besoins qu'un objet membre a besoin ).
De plus, si il y a avait pb sur le terme design pattern qui va bien, il aurait posé la question donc c'est qu'il avait compris aux quels designs patterns je faisais allusion

[popayan]

Effectivement, j'avais saisi au moins pour le pattern singleton
Ce que j'ai fait :
Une classe Connexion (qui implémente le pattern singleton) qui me retourne un objet PDO (toujours le même), une classe abstraite Model qui dans son constructeur récupère l'objet PDO. Pour moi c'est suffisant pour le moment
Comme je l'ai dit plus haut, c'est plus un exercice que quelque chose qui servira réellement... Maintenant, je commence à bosser sur un autoload correct...

[Sephi-Chan]

Citer le nom du design pattern a l'avantage de ne pas être sujet à interprétation. ^^