4 votes

Construire un vrai framework orienté objet en PHP, suggestions souhaitées

J'ai utilisé le framework CodeIgniter, mais après avoir appris Java et des fonctionnalités impressionnantes comme les interfaces, les classes abstraites, les paquets, et que PHP 5 supporte également la plupart de ces fonctionnalités, je suis prêt à obtenir mon diplôme et à construire un système de gestion de l'information. réel OO en PHP qui utilise toutes ces fonctionnalités (y compris les espaces de noms), ce qui me permet d'élaborer des conceptions beaucoup plus élégantes.

Ce à quoi je pense, c'est qu'au lieu que tous les éléments du système partagent une même $this-> comme c'est le cas dans CodeIgniter, par exemple

$this->load->model('box');
$this->box->something();

Pour charger le fichier Box et d'appeler son something() méthode.

$box = new Framework\Models\Box();
$box->something();

Ou ce qui suit

abstract class BaseController
{
   public function getModel($name)
   {
      $model = new Framework\Models\$model(); //Is this valid code?
      return $model;
   }
}

class MyController extends BaseController
{
    public function index()
    {
        $box = $this->getModel('box');
        $box->something();
   }
}

Y a-t-il des suggestions/points de repère pour construire cela, comme les classes système minimales dont j'aurais besoin pour le cadre, les espaces de noms que je devrais avoir, ou d'autres caractéristiques ?

11voto

null Points 3159

Une chose que j'ai remarquée, c'est qu'un cadre est généralement conçu dans un but précis. Les frameworks génériques (comme CodeIgniter) sont bien pour les petits sites et pour faire fonctionner les choses rapidement. Cependant, une fois que vous avez des choses spécifiques, qui sortent du cadre générique, construire votre propre framework devient une réalité.

La seule chose que je suggérerais, c'est d'être cohérent. C'est-à-dire une cohérence implacable. Si vous décidez de nommer les choses en camelCase, ne vous en écartez pas. Ou si vous décidez d'utiliser la convention NounVerb pour nommer les méthodes, c'est-à-dire spaceJump alors ne pas passer à jumpSpace même si cela "sonne" mieux à ce moment-là.

Choisissez la manière dont vous acceptez les paramètres et soyez cohérent à cet égard. Accepterez-vous uniquement des paramètres ou des tableaux associatifs de paramètres ? Choisissez et tenez-vous en à cela.

Je ne voudrais pas non plus que vous fassiez trop d'ingénierie avant d'avoir écrit quoi que ce soit. La cohérence vous mènera assez loin avant que vous n'ayez besoin de remanier... mais je n'aurais pas peur de le faire aussi. (Un ou deux tests unitaires devraient apaiser ces craintes).

Il n'y a généralement pas de bonne ou de mauvaise façon de faire les choses, tant que l'on est cohérent. Ai-je mentionné...

Soyez cohérent !

5voto

Toto Points 1173

Il faut beaucoup d'expérience pour construire un cadre technique (sans vouloir vous offenser) et il existe déjà des milliers de cadres/bibliothèques de CMS/objets de base (gestion de session, ORM, etc.).

Au lieu de perdre un temps précieux (sans vouloir vous offenser), vous feriez mieux de le faire :

  1. Évaluez et sélectionnez le cadre qui répond le mieux à vos besoins (certains ont une très bonne architecture OO).
  2. Apprenez à utiliser ce bon cadre.
  3. Construisez votre propre OO entreprise/application cadre. (C'est là que vous pouvez apprendre, vous différencier et créer de la valeur).

4voto

Andi Points 5222

Vous pouvez créer le vôtre, mais pourquoi ne pas utiliser les vastes bibliothèques incluses dans les cadres disponibles et, si nécessaire, étendre leurs fonctionnalités.

Pourquoi ne pas jeter un coup d'œil sur le framework Zend.

La prise en main est assez rapide et il comprend en standard un grand nombre de bibliothèques et de classes utiles. C'est un bon outil pour des projets personnels si vous cherchez à acquérir plus d'expérience avec la POO.

http://framework.zend.com/

3voto

Chris Domigan Points 146

Je regarderais Kohana . Il est issu de CodeIgnitor, et le chargement des modèles, etc. se fait exactement comme vous l'avez proposé.

Jetez un coup d'œil à leurs principales caractéristiques, dont beaucoup sont directement liées à votre question (je les ai mises en évidence) :

En quoi Kohana est-il différent ?

Bien que Kohana réutilise de nombreux modèles et concepts de conception courants, certains éléments le distinguent des autres :

  1. La communauté, et non l'entreprise, est au centre des préoccupations. Le développement de Kohana est mené par une équipe de personnes dévouées qui ont besoin d'un cadre pour des solutions rapides et puissantes.
  2. Strict PHP 5 OOP. Offre de nombreux avantages : protection de la visibilité, chargement automatique des classes, surcharge, interfaces, abstraits et singletons.
  3. Extrêmement léger. Kohana ne dépend pas des extensions PECL ou des bibliothèques PEAR. Les grandes bibliothèques monolithiques sont évitées au profit de solutions optimisées.
  4. Les tableaux GET, POST, COOKIE et SESSION fonctionnent tous comme prévu. Kohana ne limite pas votre accès aux données globales, mais offre un filtrage et une protection XSS.
  5. Véritable chargement automatique des classes. Véritable chargement des classes à la demande, au fur et à mesure qu'elles sont demandées dans votre application.
  6. Aucun conflit d'espace de noms. Toutes les classes sont suffixées afin de permettre l'utilisation de noms similaires entre les composants, pour une API plus cohérente.
  7. Les ressources en cascade offrent une extensibilité inégalée. Presque toutes les parties de Kohana peuvent être surchargées ou étendues sans avoir à modifier les fichiers du système principal. Les modules permettent d'ajouter des plugins multi-fichiers à votre application, de manière transparente.
  8. Pilotes de bibliothèques et cohérence de l'API. Les bibliothèques peuvent utiliser différents "pilotes" pour gérer différentes API externes de manière transparente. Par exemple, plusieurs options de stockage de session sont disponibles (base de données, cookie et native), mais la même interface est utilisée pour chacune d'entre elles. Cela permet de développer de nouveaux pilotes pour les bibliothèques existantes, ce qui maintient la cohérence et la transparence de l'API.
  9. Gestionnaire d'événements puissant. Les gestionnaires d'événements de type observateur permettent des niveaux extrêmes de personnalisation.
  10. Cycle de développement rapide. Le développement rapide permet de répondre plus rapidement aux bogues et aux demandes des utilisateurs.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X