2010-12-02 18 views
0

J'ai du mal à concevoir le script côté serveur qui répond aux requêtes d'une application Ajax. Dans son état actuel, l'application est divisée en pages distinctes (par exemple, commandes, articles, finances, etc.). Ce n'est que lorsque vous basculez entre ces pages que la page Web actuelle est rechargée. Chaque page a son propre "opérateur", qui est requis dans une racine operator.php, à laquelle sont dirigées toutes les demandes Ajax.Comment structurer un service PHP qui répond aux requêtes Ajax

contenus dans chaque opérateur est ce modèle:

foreach ($actions as $action) { 
    switch ($action) { 
    case 'get-items': 
     [...] 
     break; 
    case 'get-item': 
     [...] 
     break; 
    case 'update-item': 
     [...] 
     break; 
    [...] 
    } 
} 

Le sont fournis par la demande, par exemple, operator.php?page=items&action=get-item&id=123. À mesure que l'application devenait plus compliquée, elle aidait à séparer la logique de chaque action du contexte de l'endroit où l'action était demandée.

Je trouve que je voudrais souvent utiliser ce modèle quand je voulais utiliser une logique de l'action interne en PHP:

$items = json_decode(file_get_contents('http://[...]/operator.php?action=get-items')); 

(. Inutile de dire que cette conception crée beaucoup de frais généraux supplémentaires)

Donc à la place, j'ai maintenant une classe Operator qui est étendue par chaque page. Je peux créer, par exemple, un ItemsOperator et appeler directement l'action que je veux, sans aucun encodage ou le décodage ou les requêtes HTTP superflues:

$items = $itemsOperator->getItems(); 

J'ai modifié le script qui répond aux demandes Ajax d'utiliser la classe opérateur, comme ceci:

foreach ($actions as $action) { 
    switch ($action) { 
    case 'get-items': 
     $json['items'] = $operator->getItems(); 
     break; 
    [...] 
    } 
} 

if (count($json)) { 
    echo json_encode($json); 
} 

Cette approche fonctionne assez bien, mais je ne l'ai jamais eu de formation de développement web formel, et je pense qu'il y sont établis, les modèles mieux soustraites (que je ne peux exaspérante pas trouver sur Google) . De nombreuses lacunes avec mon approche maison ont inspiré cette question:

  1. Le concept de la classe «Opérateur» qui contient des «actions» est trop vague et englobe tout. Comment devrais-je séparer la logique? Lorsque l'approche devient particulièrement désordonnée, c'est quand je dois, par exemple, chercher les éléments DB sur la page des finances. Dois-je également inclure ItemsOperator aux côtés de FinancesOperator? (Je duplique actuellement la logique.)
  2. Existe-t-il une meilleure façon d'interfacer le script de requête Ajax avec les objets Opérateur (en supposant que je ne devrais pas vider complètement le concept d'opérateurs)? Par exemple, je dois actuellement écrire un script pour chaque page qui associe la variable "action" de l'URL à la méthode correspondante de l'objet opérateur.

Désolé, cette question est trop ouverte. Je n'ai pas de développeurs autour de moi pour échanger des idées (et comme je l'ai dit, je n'ai pas eu de véritable formation) - donc c'est inestimable d'entendre les conseils de la communauté SO. Lors de la conception d'un script comme celui-ci, le nombre de possibilités/approches/stratégies peut être totalement écrasante. Et une fois que vous avez investi quelques jours dans une approche particulière, il peut être très difficile de revenir en arrière.

Merci beaucoup pour votre considération (et lire ce point).

Répondre

0

Pas une réponse complète, mais je voudrais séparer operator.php en deux fichiers. L'un appelé operator.php et l'autre operator_ajax.php. operator.php fait ce que vous l'avez fait maintenant, mais au lieu de l'écho, il met simplement dans une variable afin qu'il puisse être inclus. operator_ajax.php inclut operator.php et renvoie la valeur. operator.php peut alors être inclus à partir de n'importe quel autre fichier que vous souhaitez (en remplaçant la requête HTTP).

+0

C'est essentiellement ce que j'ai fini par faire. Les "ajax_operators" sont inclus depuis une racine ajax_operator. Ensuite, les actions sont demandées au format 'page1.action1', donc je peux utiliser l'action d'une page d'une autre page (en supposant que l'utilisateur ait accès). De plus, je peux écrire des actions pour une page qui utilise la classe "operator" d'une autre page, puisqu'elles sont extraites de la méthode de requête (HTTP ou autre). – JKS

1

Il semble que vous auriez avantage à lire sur le modèle d'architecture Model-View-Controller (http://en.wikipedia.org/wiki/Model-View-Controller).

Où vous effectuaient ce genre de demandes:

$items = json_decode(file_get_contents('http://[...]/operator.php?action=get-items')); 

... vous devriez être encapsulant la logique dans les classes de service. Par conséquent, lorsque vous voulez faire des choses comme «Rechercher les éléments de base de données sur la page des finances», vous pouvez simplement vous fier aux services qui encapsulent la logique pour le faire. Un peu plus de lecture sur les principes de base de la programmation orientée objet irait un long chemin ainsi qu'un bref aperçu sur les modèles de conception. Je recommande de vérifier Head First Design Patterns pour un aperçu facile à comprendre de ces concepts.

+0

Appréciez les recommandations - écrivez-les maintenant! J'ai lu un peu sur le modèle MVC, mais je dois admettre que je ne comprends pas comment cela fonctionnerait dans le contexte d'une application Ajax, où la logique est séparée entre le front-end et le côté serveur. – JKS