MVC+CRUD->ESQUISSE mvc, crud, modelviewcontroller, activerecord, Source N°42769

Information sur la source

Catégorie :Class et Objet ( POO ) Classé sous : mvc, crud, modelviewcontroller, activerecord Niveau : Débutant Date de création : 20/05/2007 Vu / téléchargé: 2 191 / 137

Auteur : Arkko

Site perso

Ecrire un message privé

Note :
Aucune note

Commentaire sur cette source (7)

Ajouter un commentaire et/ou une note

Description

Bonjour,
J'ai écrit hier soir une petite esquisse d'un script selon le MVC (Model-View-Controller) et le CRUD (Create-Read-Update-Delete) + index

J'ai quelques petites interrogations comme, par exemple, instancié une classe «Active Record» dans le Model au lieu de mettre un pseudo-«active record» à même le modèle.

La requete pour creer une table bidon est dans le .sql .... (mettre vos identifiant de connexion dans le fichier includes/BaseDonnees.php)

Note, c'est en php 5 (au moins php 5.1 à cause de PDO)

Vous en pensez quoi? (Je sais que c'est pas très joli, qu'il manque des isset ...)

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

includes
- ArticleAjouterVue.php 681 octets
- ArticleControleur.php 1 462 octets
- ArticleIndexVue.php 587 octets
- ArticleLireVue.php 444 octets
- ArticleModele.php 1 630 octets
- ArticleModifierVue.php 823 octets
- ArticleSupprimerVue.php 308 octets
- BaseDonnees.php 283 octets
- Controleur.php 287 octets
index.php 623 octets
requete.sql 724 octets

Télécharger le zip

Sources de la même categorie

Toutes les sources de la catégorie Class et Objet ( POO )

Sources en rapport avec celle ci

Commentaires

Commentaire de malalam le 20/05/2007 08:58:58 administrateur CS

Hello,

merci de mettre des mots clefs.
Ensuite...as-tu réflêchi aux réelles améliorations qu'apporte un tel modèle ? Du design pattern, ça ne se fait pas à tors et à travers, parce que c'est à la mode dans les écoles d'info...
A mon goût, ton exemple comporte beaucoup trop de code redondant, trop de fichiers (je préfère 1 fichier dans un tel cas...ou 2), et trop de code tout court. Et penses aux spécificités de PHP5, comme l'abstraction, l'usinage, les itérateurs (filtre notamment, je pense à la lecture) etc.
Commentaire de codefalse le 21/05/2007 12:24:10 administrateur CS

Yop !
Malalam, qu'est-ce que l'usinage et les itérateurs (dans ce cas ?) ??? ou donne voir une url d'explications si possible (j'en cherche, mais pour le moment j'ai rien trouvé la dessus !)

Ensuite, Arkko; par rapport à ton modele, je suis d'accord avec Malalam, c'est peut-être mieux d'avoir une classe par table (voir deux si ca fait trop), avec une classe abstraite de base de donnée. Bon apres, c'est mon point de vue, et je ne l'impose pas ;).
J'ai posté ma propre vision de la chose recement, si tu veux avoir mon point de vue sur la chose :
http://www.phpcs.com/codes/TENTATIVE-APPROCHE-MODELE-CRUD-UTILISATION-CLASSE-SGBD_42650.aspx

apres je pense que ces deux modeles sont vraiments quelque chose d'interessants à creuser pour optimiser la structure des codes :)
voila voila !
Commentaire de malalam le 22/05/2007 18:32:21 administrateur CS

Usinage :
http://fr.php.net/manual/fr/language.oop5.patterns.php

Itérateurs:
http://www.php.net/~helly/php/ext/spl/
(et un sympathique tuto de FhX sur PHPCS, et quelques uns de mes codes dernièrement -cherche dans ma liste de code, il y a des scripts aynat trait à la SPL (Standard PHP Library)
Commentaire de codefalse le 23/05/2007 10:40:01 administrateur CS

ok !! merci beaucoup ! :)
Commentaire de codefalse le 23/05/2007 10:52:13 administrateur CS

bon, j'ai bien jeté un oeil sur tes liens; ,qis je n'arrive pas a comprendre à quoi sert de faire une interface. Pourrais tu m'orienter un peu s'il te plait ? De ce que j'ai compris, dans l'interface, tu va mettre les fonctions et les paramètres qu'une autre classe (qui implementera l'interface) utilisera. Mais à quoi ca sert de spécifier quelles fonctions utiliser ? J'ai vu par la suite que c'était pour une raison d'interoperabilité, mais je ne comprends pas trop le rapport là. Si tu (ou quelqu'un) pouvait m'éclairer sur la chose, je lui en serai grandement reconnaissant ! (je ne demande pas forcément une explication de deux heures, juste des bons liens seront parfaits)
Pour info j'ai cherché sur Wikipedia, mais l'explication de interface ne m'a pas eclairé, j'ai regardé tes liens Malalam, et pareil. J'ai aussi cherché sur Google, mais rien. (Il n'est pas exclu que j'ai mal cherché ! :) )
Merci de votre aide
Commentaire de malalam le 23/05/2007 18:03:51 administrateur CS

Cela permet de n'avoir qu'une seule interface pour appeler n'importe quel "pilote".
On a pas à instancier la classe mssqlDB, on passe par l'interface d'usinage, et on lui dit qu'on veut une db de type mssql. Elle gèrera les erreurs (alors que dans le premier cas, si le pilote, et donc la classe mssxqlDB n'existe pas, tu vas instancier une classe non existante, donc une erreur non gérée par ton code : c'est le debugueur interne de PHP qui va réagir.)
Cela perlet aussi de gérer d'autres chose su passage : une collection d'objets, des singletons, des multitons, etc etc...
Commentaire de malalam le 23/05/2007 19:46:14 administrateur CS

Pardon j'ai confondu l'interface d'usinage est une interface en POO...
L'interface en POO c'est un modèle strict auxquels devront se conformer les classes l'implémentant. cela sert à être plus carré, déjà...à rester logique, et cela aide évidemment les développeurs à savoir comment coder telle "fonctionnalité".
Tu veux coder une classe utilisant les méthodes itératrices, tu implémentes Iterator, et tu es obligé d'implémenter les méthodes nécessaires pour cet itérateur : valid, next, current, key.
C'est une structure.