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:
- 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.)
- 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).
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