Utilisez Zend Framework pour créer une application de base flexible

Question

Nous développons une plateforme de commerce électronique utilisant Zend Framework. Nous avons plusieurs instances de l'application en cours d'exécution, en utilisant la même base de code. Les paramètres de configuration sont utilisés pour différencier les différents magasins. Le défi auquel nous sommes confrontés, c'est que nous voulons conserver la plate-forme générale telle qu'elle est actuellement, et l'étendre plutôt que d'utiliser l'approche de configuration décrite ci-dessus. La plate-forme générale (ou l'application de base) doit contenir des contrôleurs communs, des modèles et des vues. Les fonctionnalités personnalisées (contrôleurs, modèles et vues) spécifiques à l'instance particulière doivent être contenues dans une extension distincte et, en quelque sorte, être connectées à la plate-forme principale. De cette façon, la base de code partagée est maintenue propre et pas trop gonflée.

Quelqu'un a-t-il une expérience avec une telle approche? Y a-t-il des meilleures pratiques?

Les pointeurs sont très appréciés!

Answer 1

Nous utilisons un logiciel en tant qu'application de service qui ressemble à votre plate-forme et dans notre cas, toutes les données d'instance sont stockées dans la base de données de l'instance. En ce qui concerne les fonctionnalités personnalisées (code), si elles sont entièrement personnalisées, j'imagine qu'il serait logique de modulariser ou d'empaqueter le code personnalisé dans un conteneur qui peut être référencé par l'identifiant unique du client et charger le code à la demande . C'est simple pour les modules mais évidemment plus compliqué si vous vouliez des contrôleurs individuels ou même des actions.

Certains systèmes intègrent leur propre système d'événement/rappel qui permet d'injecter des fonctionnalités, bien que cela soit plus courant pour les API publiques.

Answer 2

EDIT: Je n'avais pas remarqué les différents commentaires. Ainsi, le code personnalisé n'est pas dans un seul paquet, et il ajoute des fonctionnalités et ne remplace pas.

Le problème ici est que vous mentionnez que le code ne remplace rien, mais ajoute des fonctionnalités. Vous seriez probablement en train de regarder une forme de système de plugin, où vous auriez lu un fichier de configuration avec des noms de classes. Ces classes fourniraient des informations sur chaque plugin (c'est-à-dire si votre interface utilisateur utilise des onglets, elle aura une propriété pour le nom de l'onglet).

Cela dépend vraiment du type de fonctionnalité qui est différent par implémentation. Il pourrait être utile d'avoir plus d'informations pour fournir une solution de haut niveau.

La façon dont j'utilise PHP autoload (voir: How does OOP manage to 'include' classes stored in different files) crée des dossiers séparés en fonction du nom de la classe. Cela peut être utile pour séparer le code des autres implémentations.

Answer 3

J'ai regardé la même question récemment à mon agence et la solution que je teste actuellement implique la structure du dossier d'application suivant:

app/ 
    default/ 
      controllers/ 
      models, etc 
    ecommerce/ 
       controllers/ 
       models, etc 
lib/ 
    S24/ 
     ComponentCode.php 
modules/ 
     ecommerce/ 
        admin/ 
         controllers/ 
         models, etc 
        default/ 
          controllers/ 
          models, etc 
data, public web, temp, other ZF folders 

L'idée est le code de composant commun est stocké dans le lib , l'application modulaire est stockée dans modules et le code du site Web client individuel est stocké dans app.

Les dossiers lib/S24 et modules/ecommerce seraient communs et identiques pour chaque projet (nous SVN externe ces dossiers).

app est un répertoire de module, de sorte que les dossiers default et ecommerce créent des modules dans ZF.app/default est pour les contrôleurs par défaut (c'est-à-dire sans module). app/ecommerce contient un ensemble de contrôleurs qui étendent simplement les contrôleurs au sein de modules/ecommerce/default/controllers.

Vous pouvez ensuite étendre les fonctionnalités du app/ecommerce/controllers si vous le souhaitez, ou ajouter de nouvelles fonctionnalités. Puisque nous voulons garder le même système d'administration de module et aussi prendre en charge plusieurs systèmes d'administration (dans les URL comme www.domain.com/admin/ecommerce et www.domain.com/admin/user), nous servons l'administrateur modulaire système directement à partir du dossier modules. Toutes les pages d'administration personnalisées peuvent ensuite être ajoutées à app/admin/controllers.

// Add Controller folder 
$front->addControllerDirectory('/path/to/modules/ecommerce/admin/controllers', 'ecommerceAdmin'); 

// Add route 
$router->addRoute(
    'ecommerceAdmin', 
    new Zend_Controller_Router_Route('admin/ecommerce/:controller/:action', 
            array('module' => 'ecommerceAdmin', 
              'controller' => 'index', 
              'action' => 'index')) 
); 

Comme je le dis, je suis actuellement en train de tester cela, mais j'espère que cela donnera quelques idées pour votre propre système. Une fois que je l'ai complètement stable, j'espère écrire un article sur le sujet.