Standard OOP Techniques pour la liste des projets PHP style

Question

Je construis un site freelancing (pensez scriptlance) qui a des listes de projets à la fois sur la page d'accueil et la page d'annonces. Je pensais que ce serait une bonne chance de mettre en œuvre des techniques de POO.

Je pensais que je créerais une classe de projet qui, entre autres choses, aurait une fonction d'écho du contenu pertinent pour la page d'accueil et la liste. Je voudrais un conseil sur ma méthode proposée.

Je voudrais créer une classe de quelque chose comme:

class project { 

    ... 
    public function PrintSmallListing() {  
     echo "<div id="smallListing"> 
        <h2>Listing Title</h2> 
        <span>listing description</span> 
        ... 
       </div>"; 
      } 
    } 

ensuite sur les pages pertinentes je serais exécuter une requête de base de données en boucle puis par le résultat créer un tableau de ces objets sur la base des données de la requête. Je afficherais alors la liste des projets en bouclant le tableau d'objets et en appelant le

Cela signifie que mes requêtes ne seraient pas contenues dans mes classes, sinon j'aurais besoin d'appeler une requête séparée pour chaque liste. Donc, ma question est, est-ce une bonne façon de mettre en œuvre la POO en PHP, y at-il des pratiques suivies lors de l'utilisation de POO pour ce genre de problème? ou comment le feriez-vous personnellement?

Answer 1

Eh bien, c'est de la POO, car vous utilisez des objets. Tout ce qui utilise des objets est OOP.

Mais non, vous l'utilisez totalement faux. Ce type d'application sera impossible à maintenir dans le futur. Pour changer la conception de la page - vous devrez trouver plus de 100 fichiers et apporter les changements appropriés dans chacun d'eux. Si vous voulez créer un site OOP modulaire vraiment sympa et vous améliorer avec OOP, je vous proposerais d'utiliser un framework MVC (model-view-controller) open-source, comme cakePHP.

La pratique courante également utilisée dans MVC est la séparation de vues. Cela signifie que votre vue ne doit pas dépendre de la logique métier et que la logique métier ne doit pas dépendre de la vue. De cette façon, quand vient le temps de changer le design - vous pouvez simplement l'échanger. De plus, votre logique d'entreprise n'est pas saccagée avec diverses balises html ou fonctions de rendu.