Je developpe plusieurs module (?) pour différents sites (newsletter,
livre d'or, agenda, gestion financiere, ...) sous forme de classes
PHP.
Prenons l'exemple de la newsletter : aujourd'hui, elle n'est qu'une
classe qui représente l'interface vers ma BdD, ie: Get, GetById,
Create, Update, Delete. Je fourni aux méthodes les valeurs "propres"
(validés) grace au script principal.
Ma structure est la suivantes :
newsletter.php : le script principal
newsletter.class.php : la class Newsletter
Dans newsletter.php je fais donc :
require_once('newsletter.class.php');
$newsletter = new Newsletter;
if (isset($_REQUEST['creer_message'])) {
# Test de la validation des champs
if ($isValid)
$newsletter->Create( $_REQUEST['message'], $_REQUEST['visible'] );
}
etc...
Je me dis que ce serait plus "logique" (?) de faire tous ces test dans
la classe Newsletter. Si je ne l'ai pas fais jusqu'a aujourd'hui,
c'est parce que je me dis que l'utilisateur n'utilisera pas forcement
les même noms pour les champs.
Bon, supposons que je documente suffisement cet outil pour expliquer
qu'il faille utiliser certains noms pour les champs, comment integrer
ca proprement ?
1 - Créer une méthode Start() qui ferait un test sur plusieurs valeurs
de $_REQUEST ? Donc ne pas oublier d'appeler $newsletter->Start() au
début du script.
2 - Mettre ca dans le constructeur de la classe (mais attention lors
de l'héritage, car il faut que la classe dérivé, si elle possede un
constructeur, appelle bien le constructeur de la classe parent) ?
3 - d'autres idées
Personnellement, j'ai un a-priori négatif sur les constructeur car
j'ai peur de souvent oublier d'appeller les constructeurs des classes
meres dans les classes dérivés.
Pour info, voici ma classe Newsletter (basée sur la PHPLib) :
class Newsletter
{
var $dbTable = 'newsletter';
var $maxNews = 20;
// Newsletter::GetNewsletter
function GetNewsletter($visibles=true, $mask='*')
{
$req = sprintf( "SELECT %s FROM %s WHERE %s ORDER BY id DESC LIMIT
%d"
, $mask
, $this->dbTable
, $visibles ? "visible LIKE 'O'" : '1'
, $this->maxNews );
$db = new Je_DB_Sql($req);
De toutes façons, PHP ne connait que deux espaces de nommages (ce que je trouve à ch..., mais bon), donc... Indeed².
Ce qui me gènes avec ce principe est qu'on a très vite un code imbitable où il faut remonter toute l'arborescence possible des requires et includes pour comprendre où est déclarée une variable.
En effet, c'est plus que latent. J'utilise principalement des définitions de constantes quand je peux (m'énerve de pas pouvoir déclarer des tableaux de constantes constants, m'énerve...) et pour des templates php. Jamais plus d'un niveau, sinon c'est le bordel.
Même si d'un point de vue purement technique, l'approche OO n'est pas toujours nécessaire en PHP, elle a au moins le mérite d'ajouter un espace de nommage supplémentaire - un objet n'étant jamais à la base qu'un module instanciable.
Objet ou fonction, peu importe, ce besoin de se garder des variables non "pourrissables" (hem, encore que, global $toto...) est clair.
*proprement*. J'ai vu en PHP des exemples d'utilisation des mécanismes objets d'une débilité sans égale, et dont le seul résultat pratique est de rendre le code *définitivement* impossible à maintenir.
Amen. Je trouve que ta restriction à PHP est malheureusement sans objet si j'ose dire ;-), car une bonne vieille surcharge de tous les opérateurs (genre au hasard -> par exemple) en c++ peut également rendre "marrante" la lecture du code résultant.
Au risque de se répèter comme des vieux cons, il est plus facile de pondre des paquets de spaghettis que du code facile à maintenir, et ce quel que soit le langage (mais pas quelle que soit l'heure de la journée, entre minuit et les couvertures, c'est surtout la première catégorie).
[avertissement pour la suite : Bruno a parfaitement raison de rappeler que ce que je dis là s'applique à du web dynamique, je ne tiendrai pas le même discours sur d'autres types d'applications]
Petite précision : ce n'est pas AMHA spécifique au développement web, mais à un certain modèle d'exécution, qui est celui des CGI et de PHP, où tout doit être 'reconstruit' à chaque requête. Il est évident que dans ce modèle d'exécution, il vaut mieux faire au plus simple. Il existe d'autre modèles d'exécution (long running process) où l'OO offre un intérêt bien plus évident (cf Zope par exemple).
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la persistance d'un contexte côté serveur ne va pas changer quoi que ce soit à mon sens. Ce qui change radicalement la donne, c'est de savoir si on est en protocole connecté ou non. Ceci étant, je ne connais pas suffisement le fonctionnement interne d'un zope-like pour m'étendre sur le sujet sans commencer à raconter des conneries, donc eof pour moi là dessus
Par exemple, il faut gérer les données conditionnellement obligatoires, comme le numéro de tva intracommunautaire si l'entité est 1) une société, 2) dont le siège social fait partie de la zone euro, alors que cette données n'a pas de sens pour un particulier, etc...) Un cas d'école en OO !-)
(Attention, je n'ai pas dit "un truc simple", ni "une raison pour vouloir absolument solutionner le problème avec de la POO". Juste que c'est un cas classique en conception objet.)
On est bien d'accord, ce que je voulais dire c'est là encore, les besoins de validations (qu'ils soient implémentés en dérivant un type personne physique et personne morale et en leur demandant à chacune de se valider, ou en testant bêtement le type de personne déclarée) sera nécessairement spécifique à l'application (si tu ne facture rien, tu t'en fous du numéro de tva). Toutes les vérifications de cohérence des données seront nécessairement liées à l'application.
Dans le cadre d'une application se voulant générique (comme les CMS qui est en effet un bon exemple), on peut faire mieux et plus automatique, car on dispose d'une description informatisée de la page dont on gère le contenu.
Ca dépend de quel code, et ça dépend du type de modification. Oui.
langage), et qu'on a bien séparer la logique interne au type de sa présentation, il n'y a que la vue (template ou autre) à modifier.
Que. Mais il faudra bien le faire quand même. Et le "que" n'est pas garanti dès lors que tu changes la donnée de vue (i.e. de page).
Evidemment, si la modif "de présentation" implique en fait de modifier le modèle de données, c'est un autre débat - mais dans ce cas, ce n'est pas une simple "modif de présentation", c'est une modif de la logique applicative. Pas besoin d'aller jusque là. Si tu passes l'objet dont la vue était
affichée sur la page 4 à la page 3, rien ne te garanti (sauf éventuellement Murphy qui dit même le contraire !) que tu as les données fonctionnelles disponibles pour instancier ton bidule à son nouveau placement.
Pour des applis type CMS, il est intéressant d'avoir un 'environnement' assez générique pour être adaptable aux besoins spécifique (organisation du site, gestion des workflow de publication, types de contenus spécifiques pouvant s'intégrer à l'existant, etc).
Tout à fait, ça devient un besoin récurrent de "composants" graphiques à poser n'importe où. Tous les besoins dépendent touours de l'appli ou de son type.
modèles -, et monter des usines à gaz à la mode Java me semble parfaitement aberrant dans ce contexte. Ite missa est.
Mon expérience est qu'à vouloir deviner à l'avance si, quand et comment un programme va évoluer, le plus souvent, on se mets le doigt dans l'oeil, et on se retrouve avec un bousin monstrueux qui en théorie fait même le café, et dans la pratique est impossible à faire *effectivement* évoluer.
J'ai déjà eut souvent le même sentiment.
Il me semble aussi (mais bon, ce n'est peut-être que mon cas particulier) que cette philosophie vient avec l'expérience, et qu'il y a souvent, dans le parcours d'un programmeur, une phase où on a tendance à vouloir à tout prix mettre en oeuvre tous les beaux concepts qu'on a (plus ou moins bien...) assimilé jusque là, au lieu de se concentrer sur le problème en cours et d'y chercher une solution simple, fonctionnelle et robuste (qui n'est pas forcément, loin s'en faut, la plus facile à trouver).
C'est ce que j'appelle couramment du "code d'esthète". C'est (soit-disant) joli sur le papier, mais en pratique c'est inutilisable. Le problème c'est que j'en connais beaucoup qui restent dans cette phase toute leur vie... Quant à écrire du code robuste et penser au fail-over, faut pas rêver, déjà si on vérifie une fois sur 10 un retour de fonction c'est l'Pérou..
Mes deux centimes (et demi) Je monte les enchères à 3 centimes ;-)
John
Re,
De toutes façons, PHP ne connait que deux espaces de nommages (ce que je
trouve à ch..., mais bon), donc...
Indeed².
Ce qui me gènes avec ce principe est qu'on a très vite un code imbitable
où il faut remonter toute l'arborescence possible des requires et
includes pour comprendre où est déclarée une variable.
En effet, c'est plus que latent. J'utilise principalement des définitions
de constantes quand je peux (m'énerve de pas pouvoir déclarer des tableaux
de constantes constants, m'énerve...) et pour des templates php. Jamais
plus d'un niveau, sinon c'est le bordel.
Même si d'un point de vue purement technique, l'approche OO n'est pas
toujours nécessaire en PHP, elle a au moins le mérite d'ajouter un
espace de nommage supplémentaire - un objet n'étant jamais à la base
qu'un module instanciable.
Objet ou fonction, peu importe, ce besoin de se garder des variables non
"pourrissables" (hem, encore que, global $toto...) est clair.
*proprement*. J'ai vu en PHP des exemples d'utilisation des mécanismes
objets d'une débilité sans égale, et dont le seul résultat pratique est
de rendre le code *définitivement* impossible à maintenir.
Amen. Je trouve que ta restriction à PHP est malheureusement sans objet si
j'ose dire ;-), car une bonne vieille surcharge de tous les opérateurs
(genre au hasard -> par exemple) en c++ peut également rendre "marrante" la
lecture du code résultant.
Au risque de se répèter comme des vieux cons, il est plus facile de pondre
des paquets de spaghettis que du code facile à maintenir, et ce quel que
soit le langage (mais pas quelle que soit l'heure de la journée, entre
minuit et les couvertures, c'est surtout la première catégorie).
[avertissement pour la suite : Bruno a parfaitement raison de rappeler que
ce que je dis là s'applique à du web dynamique, je ne tiendrai pas le même
discours sur d'autres types d'applications]
Petite précision : ce n'est pas AMHA spécifique au développement web,
mais à un certain modèle d'exécution, qui est celui des CGI et de PHP,
où tout doit être 'reconstruit' à chaque requête. Il est évident que
dans ce modèle d'exécution, il vaut mieux faire au plus simple. Il
existe d'autre modèles d'exécution (long running process) où l'OO offre
un intérêt bien plus évident (cf Zope par exemple).
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la
persistance d'un contexte côté serveur ne va pas changer quoi que ce soit
à mon sens. Ce qui change radicalement la donne, c'est de savoir si on est
en protocole connecté ou non. Ceci étant, je ne connais pas suffisement le
fonctionnement interne d'un zope-like pour m'étendre sur le sujet sans
commencer à raconter des conneries, donc eof pour moi là dessus
Par exemple, il faut gérer les données conditionnellement obligatoires,
comme le numéro de tva intracommunautaire si l'entité est 1) une société,
2) dont le siège social fait partie de la zone euro, alors que cette
données n'a pas de sens pour un particulier, etc...)
Un cas d'école en OO !-)
(Attention, je n'ai pas dit "un truc simple", ni "une raison pour
vouloir absolument solutionner le problème avec de la POO". Juste que
c'est un cas classique en conception objet.)
On est bien d'accord, ce que je voulais dire c'est là encore, les besoins
de validations (qu'ils soient implémentés en dérivant un type personne
physique et personne morale et en leur demandant à chacune de se valider,
ou en testant bêtement le type de personne déclarée) sera nécessairement
spécifique à l'application (si tu ne facture rien, tu t'en fous du numéro
de tva). Toutes les vérifications de cohérence des données seront
nécessairement liées à l'application.
Dans le cadre d'une application se voulant générique (comme les CMS qui
est en effet un bon exemple), on peut faire mieux et plus automatique, car on
dispose d'une description informatisée de la page dont on gère le contenu.
Ca dépend de quel code, et ça dépend du type de modification.
Oui.
langage), et qu'on a bien séparer la logique interne au type de sa
présentation, il n'y a que la vue (template ou autre) à modifier.
Que. Mais il faudra bien le faire quand même. Et le "que" n'est pas
garanti dès lors que tu changes la donnée de vue (i.e. de page).
Evidemment, si la modif "de présentation" implique en fait de modifier
le modèle de données, c'est un autre débat - mais dans ce cas, ce n'est
pas une simple "modif de présentation", c'est une modif de la logique
applicative.
Pas besoin d'aller jusque là. Si tu passes l'objet dont la vue était
affichée sur la page 4 à la page 3, rien ne te garanti (sauf
éventuellement Murphy qui dit même le contraire !) que tu as les données
fonctionnelles disponibles pour instancier ton bidule à son nouveau
placement.
Pour des applis type CMS, il est intéressant d'avoir un 'environnement'
assez générique pour être adaptable aux besoins spécifique (organisation
du site, gestion des workflow de publication, types de contenus
spécifiques pouvant s'intégrer à l'existant, etc).
Tout à fait, ça devient un besoin récurrent de "composants" graphiques à
poser n'importe où. Tous les besoins dépendent touours de l'appli ou de
son type.
modèles -, et monter des usines à gaz à la mode Java me semble
parfaitement aberrant dans ce contexte.
Ite missa est.
Mon expérience est qu'à vouloir deviner à l'avance si, quand et comment
un programme va évoluer, le plus souvent, on se mets le doigt dans
l'oeil, et on se retrouve avec un bousin monstrueux qui en théorie fait
même le café, et dans la pratique est impossible à faire *effectivement*
évoluer.
J'ai déjà eut souvent le même sentiment.
Il me semble aussi (mais bon, ce n'est peut-être que mon cas
particulier) que cette philosophie vient avec l'expérience, et qu'il y a
souvent, dans le parcours d'un programmeur, une phase où on a tendance à
vouloir à tout prix mettre en oeuvre tous les beaux concepts qu'on a
(plus ou moins bien...) assimilé jusque là, au lieu de se concentrer sur
le problème en cours et d'y chercher une solution simple, fonctionnelle
et robuste (qui n'est pas forcément, loin s'en faut, la plus facile à
trouver).
C'est ce que j'appelle couramment du "code d'esthète". C'est (soit-disant)
joli sur le papier, mais en pratique c'est inutilisable. Le problème c'est
que j'en connais beaucoup qui restent dans cette phase toute leur vie...
Quant à écrire du code robuste et penser au fail-over, faut pas rêver,
déjà si on vérifie une fois sur 10 un retour de fonction c'est l'Pérou..
Mes deux centimes (et demi)
Je monte les enchères à 3 centimes ;-)
De toutes façons, PHP ne connait que deux espaces de nommages (ce que je trouve à ch..., mais bon), donc... Indeed².
Ce qui me gènes avec ce principe est qu'on a très vite un code imbitable où il faut remonter toute l'arborescence possible des requires et includes pour comprendre où est déclarée une variable.
En effet, c'est plus que latent. J'utilise principalement des définitions de constantes quand je peux (m'énerve de pas pouvoir déclarer des tableaux de constantes constants, m'énerve...) et pour des templates php. Jamais plus d'un niveau, sinon c'est le bordel.
Même si d'un point de vue purement technique, l'approche OO n'est pas toujours nécessaire en PHP, elle a au moins le mérite d'ajouter un espace de nommage supplémentaire - un objet n'étant jamais à la base qu'un module instanciable.
Objet ou fonction, peu importe, ce besoin de se garder des variables non "pourrissables" (hem, encore que, global $toto...) est clair.
*proprement*. J'ai vu en PHP des exemples d'utilisation des mécanismes objets d'une débilité sans égale, et dont le seul résultat pratique est de rendre le code *définitivement* impossible à maintenir.
Amen. Je trouve que ta restriction à PHP est malheureusement sans objet si j'ose dire ;-), car une bonne vieille surcharge de tous les opérateurs (genre au hasard -> par exemple) en c++ peut également rendre "marrante" la lecture du code résultant.
Au risque de se répèter comme des vieux cons, il est plus facile de pondre des paquets de spaghettis que du code facile à maintenir, et ce quel que soit le langage (mais pas quelle que soit l'heure de la journée, entre minuit et les couvertures, c'est surtout la première catégorie).
[avertissement pour la suite : Bruno a parfaitement raison de rappeler que ce que je dis là s'applique à du web dynamique, je ne tiendrai pas le même discours sur d'autres types d'applications]
Petite précision : ce n'est pas AMHA spécifique au développement web, mais à un certain modèle d'exécution, qui est celui des CGI et de PHP, où tout doit être 'reconstruit' à chaque requête. Il est évident que dans ce modèle d'exécution, il vaut mieux faire au plus simple. Il existe d'autre modèles d'exécution (long running process) où l'OO offre un intérêt bien plus évident (cf Zope par exemple).
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la persistance d'un contexte côté serveur ne va pas changer quoi que ce soit à mon sens. Ce qui change radicalement la donne, c'est de savoir si on est en protocole connecté ou non. Ceci étant, je ne connais pas suffisement le fonctionnement interne d'un zope-like pour m'étendre sur le sujet sans commencer à raconter des conneries, donc eof pour moi là dessus
Par exemple, il faut gérer les données conditionnellement obligatoires, comme le numéro de tva intracommunautaire si l'entité est 1) une société, 2) dont le siège social fait partie de la zone euro, alors que cette données n'a pas de sens pour un particulier, etc...) Un cas d'école en OO !-)
(Attention, je n'ai pas dit "un truc simple", ni "une raison pour vouloir absolument solutionner le problème avec de la POO". Juste que c'est un cas classique en conception objet.)
On est bien d'accord, ce que je voulais dire c'est là encore, les besoins de validations (qu'ils soient implémentés en dérivant un type personne physique et personne morale et en leur demandant à chacune de se valider, ou en testant bêtement le type de personne déclarée) sera nécessairement spécifique à l'application (si tu ne facture rien, tu t'en fous du numéro de tva). Toutes les vérifications de cohérence des données seront nécessairement liées à l'application.
Dans le cadre d'une application se voulant générique (comme les CMS qui est en effet un bon exemple), on peut faire mieux et plus automatique, car on dispose d'une description informatisée de la page dont on gère le contenu.
Ca dépend de quel code, et ça dépend du type de modification. Oui.
langage), et qu'on a bien séparer la logique interne au type de sa présentation, il n'y a que la vue (template ou autre) à modifier.
Que. Mais il faudra bien le faire quand même. Et le "que" n'est pas garanti dès lors que tu changes la donnée de vue (i.e. de page).
Evidemment, si la modif "de présentation" implique en fait de modifier le modèle de données, c'est un autre débat - mais dans ce cas, ce n'est pas une simple "modif de présentation", c'est une modif de la logique applicative. Pas besoin d'aller jusque là. Si tu passes l'objet dont la vue était
affichée sur la page 4 à la page 3, rien ne te garanti (sauf éventuellement Murphy qui dit même le contraire !) que tu as les données fonctionnelles disponibles pour instancier ton bidule à son nouveau placement.
Pour des applis type CMS, il est intéressant d'avoir un 'environnement' assez générique pour être adaptable aux besoins spécifique (organisation du site, gestion des workflow de publication, types de contenus spécifiques pouvant s'intégrer à l'existant, etc).
Tout à fait, ça devient un besoin récurrent de "composants" graphiques à poser n'importe où. Tous les besoins dépendent touours de l'appli ou de son type.
modèles -, et monter des usines à gaz à la mode Java me semble parfaitement aberrant dans ce contexte. Ite missa est.
Mon expérience est qu'à vouloir deviner à l'avance si, quand et comment un programme va évoluer, le plus souvent, on se mets le doigt dans l'oeil, et on se retrouve avec un bousin monstrueux qui en théorie fait même le café, et dans la pratique est impossible à faire *effectivement* évoluer.
J'ai déjà eut souvent le même sentiment.
Il me semble aussi (mais bon, ce n'est peut-être que mon cas particulier) que cette philosophie vient avec l'expérience, et qu'il y a souvent, dans le parcours d'un programmeur, une phase où on a tendance à vouloir à tout prix mettre en oeuvre tous les beaux concepts qu'on a (plus ou moins bien...) assimilé jusque là, au lieu de se concentrer sur le problème en cours et d'y chercher une solution simple, fonctionnelle et robuste (qui n'est pas forcément, loin s'en faut, la plus facile à trouver).
C'est ce que j'appelle couramment du "code d'esthète". C'est (soit-disant) joli sur le papier, mais en pratique c'est inutilisable. Le problème c'est que j'en connais beaucoup qui restent dans cette phase toute leur vie... Quant à écrire du code robuste et penser au fail-over, faut pas rêver, déjà si on vérifie une fois sur 10 un retour de fonction c'est l'Pérou..
Mes deux centimes (et demi) Je monte les enchères à 3 centimes ;-)
John
bruno modulix
John GALLET wrote: (snip)
Il existe d'autre modèles d'exécution (long running process) où l'OO offre un intérêt bien plus évident (cf Zope par exemple).
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la persistance d'un contexte côté serveur ne va pas changer quoi que ce soit à mon sens.
Le fait d'avoir une appli qui tourne en fond côté serveur fait une différence importante en ce que ça évite de devoir reconstruire le monde, l'univers et le reste à chaque requête. Dans le cas de Zope, cela signifierait réinstancier des centaines d'objets à chaque fois - je te laisse imaginer...
Cela conditionne donc fortement la façon de concevoir son appli - non qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais parce que ces buts sont atteints autrement.
Ce qui change radicalement la donne, c'est de savoir si on est en protocole connecté ou non.
Ca reste of course la différence essentielle entre une appli Web et une appli C/S classique, mais le modèle CGI (au sens large) ajoute une contrainte supplémentaire.
Mes deux centimes (et demi)
Je monte les enchères à 3 centimes ;-)
Er moi à trois centimes et demi ! qui dit mieux ?
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
John GALLET wrote:
(snip)
Il
existe d'autre modèles d'exécution (long running process) où l'OO offre
un intérêt bien plus évident (cf Zope par exemple).
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la
persistance d'un contexte côté serveur ne va pas changer quoi que ce soit
à mon sens.
Le fait d'avoir une appli qui tourne en fond côté serveur fait une
différence importante en ce que ça évite de devoir reconstruire le
monde, l'univers et le reste à chaque requête. Dans le cas de Zope, cela
signifierait réinstancier des centaines d'objets à chaque fois - je te
laisse imaginer...
Cela conditionne donc fortement la façon de concevoir son appli - non
qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais
parce que ces buts sont atteints autrement.
Ce qui change radicalement la donne, c'est de savoir si on est
en protocole connecté ou non.
Ca reste of course la différence essentielle entre une appli Web et une
appli C/S classique, mais le modèle CGI (au sens large) ajoute une
contrainte supplémentaire.
Mes deux centimes (et demi)
Je monte les enchères à 3 centimes ;-)
Er moi à trois centimes et demi ! qui dit mieux ?
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Il existe d'autre modèles d'exécution (long running process) où l'OO offre un intérêt bien plus évident (cf Zope par exemple).
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la persistance d'un contexte côté serveur ne va pas changer quoi que ce soit à mon sens.
Le fait d'avoir une appli qui tourne en fond côté serveur fait une différence importante en ce que ça évite de devoir reconstruire le monde, l'univers et le reste à chaque requête. Dans le cas de Zope, cela signifierait réinstancier des centaines d'objets à chaque fois - je te laisse imaginer...
Cela conditionne donc fortement la façon de concevoir son appli - non qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais parce que ces buts sont atteints autrement.
Ce qui change radicalement la donne, c'est de savoir si on est en protocole connecté ou non.
Ca reste of course la différence essentielle entre une appli Web et une appli C/S classique, mais le modèle CGI (au sens large) ajoute une contrainte supplémentaire.
Mes deux centimes (et demi)
Je monte les enchères à 3 centimes ;-)
Er moi à trois centimes et demi ! qui dit mieux ?
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
John GALLET
Re,
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la persistance d'un contexte côté serveur ne va pas changer quoi que ce soit à mon sens. Le fait d'avoir une appli qui tourne en fond côté serveur fait une
différence importante en ce que ça évite de devoir reconstruire le monde, l'univers et le reste à chaque requête.
J'y réfléchissais justement hier en répondant, et je ne vois pas de différence si importante que ça (pour des choses comparables). Je parle là seulement des données utilisateur, pas de tout le bordel éventuellement nécessaire au système lui même pour fonctionner.
Déjà, si on a N machines frontales en load balancing aléatoire, on est baisés avec un système qui essaie de garder les informations en RAM. Il faut impérativement trouver un load balancer qui te garanti que les N requêtes http de la session pendant toute sa durée passeront toujours sur la même bécane.
Si le load balancer ne peut pas te le garantir, il n'y a pas le choix, tu es obligé de passer par le seul point commun : le sgbdr. Donc là, pas le choix, il faut systématiquement commencer par initialiser un contexte de manière à peu près pas trop bourrinne à chaque requête http, donc tu reconstruit le monde ou la partie qui t'en intéresse à chaque fois.
Si d'une manière ou d'une autre, tu es sûr que les N requêtes de session arriveront sur la même machine physique, je suis quasiment sûr qu'il y a très peu de différences entre les sessions natives php gardées en RAM et d'autres systèmes, autres systèmes qui ont dû s'assurer que les ressources qu'ils se mettaient de côté étaient bien utilisées et non pas inactives en attendant que la session dormante soit réactivée (pendant que toto est à la pause café)
Dans le cas de Zope, cela signifierait réinstancier des centaines d'objets à chaque fois - je te laisse imaginer...
C'est cette lourdeur de fonctionnement interne que je repproche aux "serveurs d'applications" au sens large du terme. J'ai déjà vu des machines de production qui mettaient 2 ou 3 minutes pour lancer leur serveur d'appli, alors que lancer un apache plus php, ça prend moins de 10 secondes.
Cela conditionne donc fortement la façon de concevoir son appli - non qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais parce que ces buts sont atteints autrement. Pour moi, un cache ne doit qu'améliorer (ou parfois : diminuer :-)!!) les
performances du système et doit rester transparent en termes de conception (à part décider ce qui est mis en cache et quand le purger).
Ca reste of course la différence essentielle entre une appli Web et une appli C/S classique, mais le modèle CGI (au sens large) ajoute une contrainte supplémentaire.
Pour moi non à deux titres : ça ne change que le nombre de fois que l'initialisation doit avoir lieu (indépendance des requêtes http) et c'est justement parce qu'on est en protocole non connecté qu'on peut se permettre de ne pas avoir une égalité 1 client connecté = 1 process serveur qui lui est dédié. A mon sens, si un serveur d'appli est obligé de conserver en mémoire des objets qui ne lui servent à rien(1) parce qu'il n'est pas capable(2) de les réinstancier assez rapidement quand il en a besoin à la requête suivante, il y a clairement un problème... au hasard, de couches empilées qui ne servent à rien ? ;-)))
(1) : au sens que comme protocole non connecté, impossible de détecter la déconnexion, donc on garde des trucs inutiles tout le temps du time out. (2) : il faut savoir ici si garder les objets en RAM est un besoin incontournable pour raisons de performance ou un choix technique mûrement réfléchi.
Er moi à trois centimes et demi ! qui dit mieux ? Adjugé, vendu.
a++; JG
Re,
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la
persistance d'un contexte côté serveur ne va pas changer quoi que ce soit
à mon sens.
Le fait d'avoir une appli qui tourne en fond côté serveur fait une
différence importante en ce que ça évite de devoir reconstruire le
monde, l'univers et le reste à chaque requête.
J'y réfléchissais justement hier en répondant, et je ne vois pas de
différence si importante que ça (pour des choses comparables). Je parle là
seulement des données utilisateur, pas de tout le bordel éventuellement
nécessaire au système lui même pour fonctionner.
Déjà, si on a N machines frontales en load balancing aléatoire, on est
baisés avec un système qui essaie de garder les informations en RAM. Il
faut impérativement trouver un load balancer qui te garanti que les N
requêtes http de la session pendant toute sa durée passeront toujours sur
la même bécane.
Si le load balancer ne peut pas te le garantir, il n'y a pas le choix, tu
es obligé de passer par le seul point commun : le sgbdr. Donc là, pas le
choix, il faut systématiquement commencer par initialiser un contexte de
manière à peu près pas trop bourrinne à chaque requête http, donc tu
reconstruit le monde ou la partie qui t'en intéresse à chaque fois.
Si d'une manière ou d'une autre, tu es sûr que les N requêtes de session
arriveront sur la même machine physique, je suis quasiment sûr qu'il y a
très peu de différences entre les sessions natives php gardées en RAM et
d'autres systèmes, autres systèmes qui ont dû s'assurer que les ressources
qu'ils se mettaient de côté étaient bien utilisées et non pas inactives en
attendant que la session dormante soit réactivée (pendant que toto est à
la pause café)
Dans le cas de Zope, cela
signifierait réinstancier des centaines d'objets à chaque fois - je te
laisse imaginer...
C'est cette lourdeur de fonctionnement interne que je repproche aux
"serveurs d'applications" au sens large du terme. J'ai déjà vu des
machines de production qui mettaient 2 ou 3 minutes pour lancer leur
serveur d'appli, alors que lancer un apache plus php, ça prend moins de 10
secondes.
Cela conditionne donc fortement la façon de concevoir son appli - non
qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais
parce que ces buts sont atteints autrement.
Pour moi, un cache ne doit qu'améliorer (ou parfois : diminuer :-)!!) les
performances du système et doit rester transparent en termes de
conception (à part décider ce qui est mis en cache et quand le purger).
Ca reste of course la différence essentielle entre une appli Web et une
appli C/S classique, mais le modèle CGI (au sens large) ajoute une
contrainte supplémentaire.
Pour moi non à deux titres : ça ne change que le nombre de fois que
l'initialisation doit avoir lieu (indépendance des requêtes http) et c'est
justement parce qu'on est en protocole non connecté qu'on peut se
permettre de ne pas avoir une égalité 1 client connecté = 1 process
serveur qui lui est dédié. A mon sens, si un serveur d'appli est obligé de
conserver en mémoire des objets qui ne lui servent à rien(1) parce qu'il
n'est pas capable(2) de les réinstancier assez rapidement quand il en a
besoin à la requête suivante, il y a clairement un problème... au hasard,
de couches empilées qui ne servent à rien ? ;-)))
(1) : au sens que comme protocole non connecté, impossible de détecter la
déconnexion, donc on garde des trucs inutiles tout le temps du time out.
(2) : il faut savoir ici si garder les objets en RAM est un besoin
incontournable pour raisons de performance ou un choix technique mûrement
réfléchi.
Er moi à trois centimes et demi ! qui dit mieux ?
Adjugé, vendu.
Très clairement, ça s'applique à tout ce qui est "cgi-like". Mais la persistance d'un contexte côté serveur ne va pas changer quoi que ce soit à mon sens. Le fait d'avoir une appli qui tourne en fond côté serveur fait une
différence importante en ce que ça évite de devoir reconstruire le monde, l'univers et le reste à chaque requête.
J'y réfléchissais justement hier en répondant, et je ne vois pas de différence si importante que ça (pour des choses comparables). Je parle là seulement des données utilisateur, pas de tout le bordel éventuellement nécessaire au système lui même pour fonctionner.
Déjà, si on a N machines frontales en load balancing aléatoire, on est baisés avec un système qui essaie de garder les informations en RAM. Il faut impérativement trouver un load balancer qui te garanti que les N requêtes http de la session pendant toute sa durée passeront toujours sur la même bécane.
Si le load balancer ne peut pas te le garantir, il n'y a pas le choix, tu es obligé de passer par le seul point commun : le sgbdr. Donc là, pas le choix, il faut systématiquement commencer par initialiser un contexte de manière à peu près pas trop bourrinne à chaque requête http, donc tu reconstruit le monde ou la partie qui t'en intéresse à chaque fois.
Si d'une manière ou d'une autre, tu es sûr que les N requêtes de session arriveront sur la même machine physique, je suis quasiment sûr qu'il y a très peu de différences entre les sessions natives php gardées en RAM et d'autres systèmes, autres systèmes qui ont dû s'assurer que les ressources qu'ils se mettaient de côté étaient bien utilisées et non pas inactives en attendant que la session dormante soit réactivée (pendant que toto est à la pause café)
Dans le cas de Zope, cela signifierait réinstancier des centaines d'objets à chaque fois - je te laisse imaginer...
C'est cette lourdeur de fonctionnement interne que je repproche aux "serveurs d'applications" au sens large du terme. J'ai déjà vu des machines de production qui mettaient 2 ou 3 minutes pour lancer leur serveur d'appli, alors que lancer un apache plus php, ça prend moins de 10 secondes.
Cela conditionne donc fortement la façon de concevoir son appli - non qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais parce que ces buts sont atteints autrement. Pour moi, un cache ne doit qu'améliorer (ou parfois : diminuer :-)!!) les
performances du système et doit rester transparent en termes de conception (à part décider ce qui est mis en cache et quand le purger).
Ca reste of course la différence essentielle entre une appli Web et une appli C/S classique, mais le modèle CGI (au sens large) ajoute une contrainte supplémentaire.
Pour moi non à deux titres : ça ne change que le nombre de fois que l'initialisation doit avoir lieu (indépendance des requêtes http) et c'est justement parce qu'on est en protocole non connecté qu'on peut se permettre de ne pas avoir une égalité 1 client connecté = 1 process serveur qui lui est dédié. A mon sens, si un serveur d'appli est obligé de conserver en mémoire des objets qui ne lui servent à rien(1) parce qu'il n'est pas capable(2) de les réinstancier assez rapidement quand il en a besoin à la requête suivante, il y a clairement un problème... au hasard, de couches empilées qui ne servent à rien ? ;-)))
(1) : au sens que comme protocole non connecté, impossible de détecter la déconnexion, donc on garde des trucs inutiles tout le temps du time out. (2) : il faut savoir ici si garder les objets en RAM est un besoin incontournable pour raisons de performance ou un choix technique mûrement réfléchi.
Er moi à trois centimes et demi ! qui dit mieux ? Adjugé, vendu.
a++; JG
bruno modulix
John GALLET wrote:
Re,
Le fait d'avoir une appli qui tourne en fond côté serveur fait une différence importante en ce que ça évite de devoir reconstruire le monde, l'univers et le reste à chaque requête.
J'y réfléchissais justement hier en répondant, et je ne vois pas de différence si importante que ça (pour des choses comparables). Je parle là seulement des données utilisateur, pas de tout le bordel éventuellement nécessaire au système lui même pour fonctionner.
Si tu penses aux données de session, effectivement, ça ne change rien de ce point de vue là. Pour ma part, c'est précisément de "tout le bordel éventuellement nécessaire au système lui même" que je parlais !-) Mais il s'avère que dans la plupart des CMS que j'ai vu, cette partie est très loin d'être négligeable.
(snip)
Si le load balancer ne peut pas te le garantir, il n'y a pas le choix, tu es obligé de passer par le seul point commun : le sgbdr.
<troll> Un SGBDR ? Pour quoi faire ?-) </troll>
(snip - je ne vais pas faire le détail des solutions de load balancing avec ZEO)
Dans le cas de Zope, cela signifierait réinstancier des centaines d'objets à chaque fois - je te laisse imaginer...
C'est cette lourdeur de fonctionnement interne que je repproche aux "serveurs d'applications" au sens large du terme. J'ai déjà vu des machines de production qui mettaient 2 ou 3 minutes pour lancer leur serveur d'appli, alors que lancer un apache plus php, ça prend moins de 10 secondes.
Outre que les instances de Zope que nous hébergeons démarrent largement assez vite, le fait est qu'il est rarement besoin de les redémarrer.
Il est clair que Zope est plus 'lourd' que PHP seul - mais pas plus que PHP + Apache + MySQL, et dans le cadre qui m'intéresse en premier lieu actuellement (gestion de contenu), nettement plus performant (temps de réponse) et très nettement plus productif (temps développeur) que PHP/MySQL, pour des applis comparables.
<demi-troll> Après, si tu penses à des trucs genre usines à gaz J2EE, je veux bien croire que tu ai des reproche à leur faire en matière de lourdeur. C'est bien toi qui parlais de bombe atomique pour écraser les mouches ?-) </demi-troll>
Cela conditionne donc fortement la façon de concevoir son appli - non qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais parce que ces buts sont atteints autrement.
Pour moi, un cache ne doit qu'améliorer (ou parfois : diminuer :-)!!) les performances du système et doit rester transparent en termes de conception (à part décider ce qui est mis en cache et quand le purger).
Ce n'est pas une histoire de "cache" (encore qu'il y en ait aussi qui rentre en jeu, mais je n'ai guère eu besoin de m'en préoccuper pour le moment - il faut croire qu'ils sont suffisament transparents !-). La différence vient du fait d'avoir un système déjà opérationnel vs devoir relancer et réinitialiser le système à chaque requête. Pour caricturer : est-ce que tu imaginerais de devoir relancer le serveur web et le SGBDR à chaque requête ?-)
Je passe sur le reste, car il faudrait que je te fasse un cours sur Zope pour y répondre - ce qui serait hors-sujet ici et me prendrait (au moins) le reste de la journée.
Cordialement, -- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
John GALLET wrote:
Re,
Le fait d'avoir une appli qui tourne en fond côté serveur fait une
différence importante en ce que ça évite de devoir reconstruire le
monde, l'univers et le reste à chaque requête.
J'y réfléchissais justement hier en répondant, et je ne vois pas de
différence si importante que ça (pour des choses comparables). Je parle là
seulement des données utilisateur, pas de tout le bordel éventuellement
nécessaire au système lui même pour fonctionner.
Si tu penses aux données de session, effectivement, ça ne change rien de
ce point de vue là. Pour ma part, c'est précisément de "tout le bordel
éventuellement nécessaire au système lui même" que je parlais !-) Mais
il s'avère que dans la plupart des CMS que j'ai vu, cette partie est
très loin d'être négligeable.
(snip)
Si le load balancer ne peut pas te le garantir, il n'y a pas le choix, tu
es obligé de passer par le seul point commun : le sgbdr.
<troll>
Un SGBDR ? Pour quoi faire ?-)
</troll>
(snip - je ne vais pas faire le détail des solutions de load balancing
avec ZEO)
Dans le cas de Zope, cela
signifierait réinstancier des centaines d'objets à chaque fois - je te
laisse imaginer...
C'est cette lourdeur de fonctionnement interne que je repproche aux
"serveurs d'applications" au sens large du terme. J'ai déjà vu des
machines de production qui mettaient 2 ou 3 minutes pour lancer leur
serveur d'appli, alors que lancer un apache plus php, ça prend moins de 10
secondes.
Outre que les instances de Zope que nous hébergeons démarrent largement
assez vite, le fait est qu'il est rarement besoin de les redémarrer.
Il est clair que Zope est plus 'lourd' que PHP seul - mais pas plus que
PHP + Apache + MySQL, et dans le cadre qui m'intéresse en premier lieu
actuellement (gestion de contenu), nettement plus performant (temps de
réponse) et très nettement plus productif (temps développeur) que
PHP/MySQL, pour des applis comparables.
<demi-troll>
Après, si tu penses à des trucs genre usines à gaz J2EE, je veux bien
croire que tu ai des reproche à leur faire en matière de lourdeur. C'est
bien toi qui parlais de bombe atomique pour écraser les mouches ?-)
</demi-troll>
Cela conditionne donc fortement la façon de concevoir son appli - non
qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais
parce que ces buts sont atteints autrement.
Pour moi, un cache ne doit qu'améliorer (ou parfois : diminuer :-)!!) les
performances du système et doit rester transparent en termes de
conception (à part décider ce qui est mis en cache et quand le purger).
Ce n'est pas une histoire de "cache" (encore qu'il y en ait aussi qui
rentre en jeu, mais je n'ai guère eu besoin de m'en préoccuper pour le
moment - il faut croire qu'ils sont suffisament transparents !-). La
différence vient du fait d'avoir un système déjà opérationnel vs devoir
relancer et réinitialiser le système à chaque requête. Pour caricturer :
est-ce que tu imaginerais de devoir relancer le serveur web et le SGBDR
à chaque requête ?-)
Je passe sur le reste, car il faudrait que je te fasse un cours sur Zope
pour y répondre - ce qui serait hors-sujet ici et me prendrait (au
moins) le reste de la journée.
Cordialement,
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Le fait d'avoir une appli qui tourne en fond côté serveur fait une différence importante en ce que ça évite de devoir reconstruire le monde, l'univers et le reste à chaque requête.
J'y réfléchissais justement hier en répondant, et je ne vois pas de différence si importante que ça (pour des choses comparables). Je parle là seulement des données utilisateur, pas de tout le bordel éventuellement nécessaire au système lui même pour fonctionner.
Si tu penses aux données de session, effectivement, ça ne change rien de ce point de vue là. Pour ma part, c'est précisément de "tout le bordel éventuellement nécessaire au système lui même" que je parlais !-) Mais il s'avère que dans la plupart des CMS que j'ai vu, cette partie est très loin d'être négligeable.
(snip)
Si le load balancer ne peut pas te le garantir, il n'y a pas le choix, tu es obligé de passer par le seul point commun : le sgbdr.
<troll> Un SGBDR ? Pour quoi faire ?-) </troll>
(snip - je ne vais pas faire le détail des solutions de load balancing avec ZEO)
Dans le cas de Zope, cela signifierait réinstancier des centaines d'objets à chaque fois - je te laisse imaginer...
C'est cette lourdeur de fonctionnement interne que je repproche aux "serveurs d'applications" au sens large du terme. J'ai déjà vu des machines de production qui mettaient 2 ou 3 minutes pour lancer leur serveur d'appli, alors que lancer un apache plus php, ça prend moins de 10 secondes.
Outre que les instances de Zope que nous hébergeons démarrent largement assez vite, le fait est qu'il est rarement besoin de les redémarrer.
Il est clair que Zope est plus 'lourd' que PHP seul - mais pas plus que PHP + Apache + MySQL, et dans le cadre qui m'intéresse en premier lieu actuellement (gestion de contenu), nettement plus performant (temps de réponse) et très nettement plus productif (temps développeur) que PHP/MySQL, pour des applis comparables.
<demi-troll> Après, si tu penses à des trucs genre usines à gaz J2EE, je veux bien croire que tu ai des reproche à leur faire en matière de lourdeur. C'est bien toi qui parlais de bombe atomique pour écraser les mouches ?-) </demi-troll>
Cela conditionne donc fortement la façon de concevoir son appli - non qu'il n'y ait plus à se soucier de simplicité et d'efficacité, mais parce que ces buts sont atteints autrement.
Pour moi, un cache ne doit qu'améliorer (ou parfois : diminuer :-)!!) les performances du système et doit rester transparent en termes de conception (à part décider ce qui est mis en cache et quand le purger).
Ce n'est pas une histoire de "cache" (encore qu'il y en ait aussi qui rentre en jeu, mais je n'ai guère eu besoin de m'en préoccuper pour le moment - il faut croire qu'ils sont suffisament transparents !-). La différence vient du fait d'avoir un système déjà opérationnel vs devoir relancer et réinitialiser le système à chaque requête. Pour caricturer : est-ce que tu imaginerais de devoir relancer le serveur web et le SGBDR à chaque requête ?-)
Je passe sur le reste, car il faudrait que je te fasse un cours sur Zope pour y répondre - ce qui serait hors-sujet ici et me prendrait (au moins) le reste de la journée.
Cordialement, -- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
