dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est le genre de macro-instructions que l'on crée, pour alléger le code du constructeur par exemple.
Enfin dans ce cas ca reste a peu près la meme chose, c'est un peu comme le bon chasseur et le mauvais chasseur non ?
ben non, dans le deuxieme cas tu n'as pas de passage de paramètres, tu te fondes uniquement sur l'état de l'objet, ce qui pour moi est quand même plus sûr, non ?
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Kupee wrote:
Dominique Marie wrote:
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est
le genre de macro-instructions que l'on crée, pour alléger le code du
constructeur par exemple.
Enfin dans ce cas ca reste a peu près la meme chose, c'est un peu comme
le bon chasseur et le mauvais chasseur non ?
ben non, dans le deuxieme cas tu n'as pas de passage de paramètres, tu te
fondes uniquement sur l'état de l'objet, ce qui pour moi est quand même
plus sûr, non ?
--
Dominique
remplacer nospam par com dans mon adresse pour m'écrire
dans le deuxieme cas, j'aurais mis le add(label) dans creerLabel(), c'est le genre de macro-instructions que l'on crée, pour alléger le code du constructeur par exemple.
Enfin dans ce cas ca reste a peu près la meme chose, c'est un peu comme le bon chasseur et le mauvais chasseur non ?
ben non, dans le deuxieme cas tu n'as pas de passage de paramètres, tu te fondes uniquement sur l'état de l'objet, ce qui pour moi est quand même plus sûr, non ?
-- Dominique
remplacer nospam par com dans mon adresse pour m'écrire
Emmanuel Bourg
Nicolas Delsaux wrote:
Je ne dis pas qu'elles sont à banir. Je dis que le design séparant d'un côté les conteneurs de données et de l'autre les managers de ces conteneurs est mauvais, car il s'appuie en fait sur la séparation entre struct e t fonction du C. Or on retrouve ce design dans la majeure partie des applications J2EE qui, il faut bien le reconnaître, font vivre à l' heure actuelle bon nombre de développeurs Java.
En quoi est ce aberrant dans la mesure ou l'on rencontre souvent des traitements opérant sur de multiples données en même temps et n'é tant pas plus particulièrement dépendants d'un conteneur de données que d'un autre ? Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à pros crire ? On devrait tout mettre dans la même classe ? Je suis assez intéressé par ta conception des systèmes d'information, peux tu nous indiquer quelque s ressources où s'instruire sur cette architecture révolutionnaire que tout le monde semble ignorer ?
Emmanuel
Nicolas Delsaux wrote:
Je ne dis pas qu'elles sont à banir. Je dis que le design séparant d'un
côté les conteneurs de données et de l'autre les managers de ces conteneurs
est mauvais, car il s'appuie en fait sur la séparation entre struct e t
fonction du C. Or on retrouve ce design dans la majeure partie des
applications J2EE qui, il faut bien le reconnaître, font vivre à l' heure
actuelle bon nombre de développeurs Java.
En quoi est ce aberrant dans la mesure ou l'on rencontre souvent des
traitements opérant sur de multiples données en même temps et n'é tant
pas plus particulièrement dépendants d'un conteneur de données que d'un
autre ? Si je poursuis ton raisonnement les architectures de type MVC
prônant une séparation des données et des traitements sont à pros crire ?
On devrait tout mettre dans la même classe ? Je suis assez intéressé par
ta conception des systèmes d'information, peux tu nous indiquer quelque s
ressources où s'instruire sur cette architecture révolutionnaire que
tout le monde semble ignorer ?
Je ne dis pas qu'elles sont à banir. Je dis que le design séparant d'un côté les conteneurs de données et de l'autre les managers de ces conteneurs est mauvais, car il s'appuie en fait sur la séparation entre struct e t fonction du C. Or on retrouve ce design dans la majeure partie des applications J2EE qui, il faut bien le reconnaître, font vivre à l' heure actuelle bon nombre de développeurs Java.
En quoi est ce aberrant dans la mesure ou l'on rencontre souvent des traitements opérant sur de multiples données en même temps et n'é tant pas plus particulièrement dépendants d'un conteneur de données que d'un autre ? Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à pros crire ? On devrait tout mettre dans la même classe ? Je suis assez intéressé par ta conception des systèmes d'information, peux tu nous indiquer quelque s ressources où s'instruire sur cette architecture révolutionnaire que tout le monde semble ignorer ?
Emmanuel
MacTotoche
Emmanuel Bourg wrote:
Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à proscrire ? MVC sépare les données des traitements ????
Et moi qui croyais qu'il isolait la Vue ( != data !!!) du Modèle ( != traitements !!!), que l'intérêt du Modèle c'était justement d'agréger données et traitements en les isolant de l'IHM.
Quel bouquin, quel prof ou quelle page web présente MVC comme ça ? Ca m'intéresse aussi beaucoup :-)
-- Olivier This space for sale.
Emmanuel Bourg wrote:
Si je poursuis ton raisonnement les architectures de type MVC
prônant une séparation des données et des traitements sont à proscrire ?
MVC sépare les données des traitements ????
Et moi qui croyais qu'il isolait la Vue ( != data !!!) du Modèle ( !=
traitements !!!), que l'intérêt du Modèle c'était justement d'agréger
données et traitements en les isolant de l'IHM.
Quel bouquin, quel prof ou quelle page web présente MVC comme ça ?
Ca m'intéresse aussi beaucoup :-)
Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à proscrire ? MVC sépare les données des traitements ????
Et moi qui croyais qu'il isolait la Vue ( != data !!!) du Modèle ( != traitements !!!), que l'intérêt du Modèle c'était justement d'agréger données et traitements en les isolant de l'IHM.
Quel bouquin, quel prof ou quelle page web présente MVC comme ça ? Ca m'intéresse aussi beaucoup :-)
-- Olivier This space for sale.
MacTotoche
Emmanuel Bourg wrote:
Tu as oublié le C de MVC :) C'est "seulement" une couche d'abstraction ou de dispatching selon le
niveau de conceptualisation auquel on veut le considérer. C'est donc bien lui qui finit d'isoler M de V, mais en rien les données des traitements.
J'aimerais toujours savoir dans quel univers le paradigme MVC prétendrait séparer les données des traitements !
Bon, je vais quand-même pas faire dégénérer la discussion, mais il faut admettre que ce troll java/php a été lancé beaucoup plus finement que celui de l'autre kador sur java/ressources :-)
MacTotoche wrote:
Emmanuel Bourg wrote:
Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à proscrire ?
MVC sépare les données des traitements ????
Et moi qui croyais qu'il isolait la Vue ( != data !!!) du Modèle ( != traitements !!!), que l'intérêt du Modèle c'était justement d'agréger données et traitements en les isolant de l'IHM.
Quel bouquin, quel prof ou quelle page web présente MVC comme ça ? Ca m'intéresse aussi beaucoup :-)
-- Olivier This space for sale.
Emmanuel Bourg wrote:
Tu as oublié le C de MVC :)
C'est "seulement" une couche d'abstraction ou de dispatching selon le
niveau de conceptualisation auquel on veut le considérer.
C'est donc bien lui qui finit d'isoler M de V, mais en rien les
données des traitements.
J'aimerais toujours savoir dans quel univers le paradigme MVC
prétendrait séparer les données des traitements !
Bon, je vais quand-même pas faire dégénérer la discussion, mais il
faut admettre que ce troll java/php a été lancé beaucoup plus finement
que celui de l'autre kador sur java/ressources :-)
MacTotoche wrote:
Emmanuel Bourg wrote:
Si je poursuis ton raisonnement les architectures de type MVC prônant
une séparation des données et des traitements sont à proscrire ?
MVC sépare les données des traitements ????
Et moi qui croyais qu'il isolait la Vue ( != data !!!) du Modèle ( !=
traitements !!!), que l'intérêt du Modèle c'était justement d'agréger
données et traitements en les isolant de l'IHM.
Quel bouquin, quel prof ou quelle page web présente MVC comme ça ?
Ca m'intéresse aussi beaucoup :-)
Tu as oublié le C de MVC :) C'est "seulement" une couche d'abstraction ou de dispatching selon le
niveau de conceptualisation auquel on veut le considérer. C'est donc bien lui qui finit d'isoler M de V, mais en rien les données des traitements.
J'aimerais toujours savoir dans quel univers le paradigme MVC prétendrait séparer les données des traitements !
Bon, je vais quand-même pas faire dégénérer la discussion, mais il faut admettre que ce troll java/php a été lancé beaucoup plus finement que celui de l'autre kador sur java/ressources :-)
MacTotoche wrote:
Emmanuel Bourg wrote:
Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à proscrire ?
MVC sépare les données des traitements ????
Et moi qui croyais qu'il isolait la Vue ( != data !!!) du Modèle ( != traitements !!!), que l'intérêt du Modèle c'était justement d'agréger données et traitements en les isolant de l'IHM.
Quel bouquin, quel prof ou quelle page web présente MVC comme ça ? Ca m'intéresse aussi beaucoup :-)
-- Olivier This space for sale.
Nicolas Delsaux
Le 06.08 2003, Emmanuel Bourg s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
En quoi est ce aberrant dans la mesure ou l'on rencontre souvent des traitements opérant sur de multiples données en même temps et n'étant pas plus particulièrement dépendants d'un conteneur de données que d'un autre ?
Dans un vrai design objet, ça n'arrive jamais, ce genre de choses. Tu peux être amené parfois à manipuler dans une classe des objets d'autres classes, évidement, mais je n'ai jamais vu d'applis où un objet manipule, comme tu le dis, des données de multiples classes différentes en même temps.
Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à proscrire ?
Pas du tout, le design MVC sépare la vue du modèle et du contrôleur. Or on trouve dans chacun de ces trois éléments des données et des traitements. Le cas typique d'applications Swing devrait suffir à te le démontrer. Dans une appli Swing, la vue contient des données, ainsi évidement que des méthodes, et il en va de même pour le modèle.
On devrait tout mettre dans la même classe ?
Ai-je également dit ça ? Je dis juste que dans une classe, il est normal et naturel de disposer de données (les variables) et de traitements (les méthodes), sinon, le concept même de classe ne présenterait aucun intérêt.
Je suis assez intéressé par ta conception des systèmes d'information, peux tu nous indiquer quelques ressources où s'instruire sur cette architecture révolutionnaire que tout le monde semble ignorer ?
On va dire par exemple, je sais pas, moi, n'importe quel bouquin traitant de l'objet.
Emmanuel
-- Nicolas Delsaux "Celui qui sait en quoi consiste l'action humaine nourrit ce que sa conscience saisit au moyen de ce qu'elle ne saisit pas." Tchouang-Tseu
Le 06.08 2003, Emmanuel Bourg <smanux@lfjr.net> s'est levé(e) et s'est
dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
En quoi est ce aberrant dans la mesure ou l'on rencontre souvent des
traitements opérant sur de multiples données en même temps et n'étant
pas plus particulièrement dépendants d'un conteneur de données que
d'un autre ?
Dans un vrai design objet, ça n'arrive jamais, ce genre de choses. Tu
peux être amené parfois à manipuler dans une classe des objets d'autres
classes, évidement, mais je n'ai jamais vu d'applis où un objet
manipule, comme tu le dis, des données de multiples classes différentes
en même temps.
Si je poursuis ton raisonnement les architectures de type MVC
prônant une séparation des données et des traitements sont à proscrire
?
Pas du tout, le design MVC sépare la vue du modèle et du contrôleur. Or
on trouve dans chacun de ces trois éléments des données et des
traitements. Le cas typique d'applications Swing devrait suffir à te le
démontrer. Dans une appli Swing, la vue contient des données, ainsi
évidement que des méthodes, et il en va de même pour le modèle.
On devrait tout mettre dans la même classe ?
Ai-je également dit ça ?
Je dis juste que dans une classe, il est normal et naturel de disposer
de données (les variables) et de traitements (les méthodes), sinon, le
concept même de classe ne présenterait aucun intérêt.
Je suis assez intéressé par
ta conception des systèmes d'information, peux tu nous indiquer
quelques ressources où s'instruire sur cette architecture
révolutionnaire que tout le monde semble ignorer ?
On va dire par exemple, je sais pas, moi, n'importe quel bouquin
traitant de l'objet.
Emmanuel
--
Nicolas Delsaux
"Celui qui sait en quoi consiste l'action humaine nourrit ce que sa
conscience saisit au moyen de ce qu'elle ne saisit pas." Tchouang-Tseu
Le 06.08 2003, Emmanuel Bourg s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
En quoi est ce aberrant dans la mesure ou l'on rencontre souvent des traitements opérant sur de multiples données en même temps et n'étant pas plus particulièrement dépendants d'un conteneur de données que d'un autre ?
Dans un vrai design objet, ça n'arrive jamais, ce genre de choses. Tu peux être amené parfois à manipuler dans une classe des objets d'autres classes, évidement, mais je n'ai jamais vu d'applis où un objet manipule, comme tu le dis, des données de multiples classes différentes en même temps.
Si je poursuis ton raisonnement les architectures de type MVC prônant une séparation des données et des traitements sont à proscrire ?
Pas du tout, le design MVC sépare la vue du modèle et du contrôleur. Or on trouve dans chacun de ces trois éléments des données et des traitements. Le cas typique d'applications Swing devrait suffir à te le démontrer. Dans une appli Swing, la vue contient des données, ainsi évidement que des méthodes, et il en va de même pour le modèle.
On devrait tout mettre dans la même classe ?
Ai-je également dit ça ? Je dis juste que dans une classe, il est normal et naturel de disposer de données (les variables) et de traitements (les méthodes), sinon, le concept même de classe ne présenterait aucun intérêt.
Je suis assez intéressé par ta conception des systèmes d'information, peux tu nous indiquer quelques ressources où s'instruire sur cette architecture révolutionnaire que tout le monde semble ignorer ?
On va dire par exemple, je sais pas, moi, n'importe quel bouquin traitant de l'objet.
Emmanuel
-- Nicolas Delsaux "Celui qui sait en quoi consiste l'action humaine nourrit ce que sa conscience saisit au moyen de ce qu'elle ne saisit pas." Tchouang-Tseu
Emmanuel Bourg
MacTotoche wrote:
C'est "seulement" une couche d'abstraction ou de dispatching selon le niveau de conceptualisation auquel on veut le considérer. C'est donc bien lui qui finit d'isoler M de V, mais en rien les donné es des traitements.
J'aimerais toujours savoir dans quel univers le paradigme MVC prétendrait séparer les données des traitements !
Tu ne peux pas demander à ton modèle de gérer tous les processus auxquels il peut participer, par exemple la persistance. Il est absurde de charger l'objet avec toutes les responsabilités possibles. C'est là que le *C*ontrôleur intervient. Par contre l'autre extrême consistant à sortir les méthodes de l'objet pour ne laisser que les données n'est pas non plus enviable, on ne gagne pas grand chose par rapport à un simple struct C effectivement si ce n'est l'héritage. L'objet doit conserver les méthodes suffisantes pour gérer son état et faciliter sa manipulation élémentaire.
Bon, je vais quand-même pas faire dégénérer la discussion, mais il faut admettre que ce troll java/php a été lancé beaucoup plus finement que celui de l'autre kador sur java/ressources :-)
Oui on arrive quand même à parler de choses intéressantes sur un tr oll PHP/Java, c'est fort :)
MacTotoche wrote:
C'est "seulement" une couche d'abstraction ou de dispatching selon le
niveau de conceptualisation auquel on veut le considérer.
C'est donc bien lui qui finit d'isoler M de V, mais en rien les donné es
des traitements.
J'aimerais toujours savoir dans quel univers le paradigme MVC
prétendrait séparer les données des traitements !
Tu ne peux pas demander à ton modèle de gérer tous les processus
auxquels il peut participer, par exemple la persistance. Il est absurde
de charger l'objet avec toutes les responsabilités possibles. C'est là
que le *C*ontrôleur intervient. Par contre l'autre extrême consistant à
sortir les méthodes de l'objet pour ne laisser que les données n'est pas
non plus enviable, on ne gagne pas grand chose par rapport à un simple
struct C effectivement si ce n'est l'héritage. L'objet doit conserver
les méthodes suffisantes pour gérer son état et faciliter sa
manipulation élémentaire.
Bon, je vais quand-même pas faire dégénérer la discussion, mais il faut
admettre que ce troll java/php a été lancé beaucoup plus finement que
celui de l'autre kador sur java/ressources :-)
Oui on arrive quand même à parler de choses intéressantes sur un tr oll
PHP/Java, c'est fort :)
C'est "seulement" une couche d'abstraction ou de dispatching selon le niveau de conceptualisation auquel on veut le considérer. C'est donc bien lui qui finit d'isoler M de V, mais en rien les donné es des traitements.
J'aimerais toujours savoir dans quel univers le paradigme MVC prétendrait séparer les données des traitements !
Tu ne peux pas demander à ton modèle de gérer tous les processus auxquels il peut participer, par exemple la persistance. Il est absurde de charger l'objet avec toutes les responsabilités possibles. C'est là que le *C*ontrôleur intervient. Par contre l'autre extrême consistant à sortir les méthodes de l'objet pour ne laisser que les données n'est pas non plus enviable, on ne gagne pas grand chose par rapport à un simple struct C effectivement si ce n'est l'héritage. L'objet doit conserver les méthodes suffisantes pour gérer son état et faciliter sa manipulation élémentaire.
Bon, je vais quand-même pas faire dégénérer la discussion, mais il faut admettre que ce troll java/php a été lancé beaucoup plus finement que celui de l'autre kador sur java/ressources :-)
Oui on arrive quand même à parler de choses intéressantes sur un tr oll PHP/Java, c'est fort :)
Emmanuel Bourg
Dominique Marie wrote:
STOP !!! Grosse bêtise, le MVC prône la séparation de la logique de traitement de celle de présentation. Ne pas confondre !!!
J'aurais pu rajouter "et de la logique de présentation", mais ça n'illustrait pas mon propos. Merci tout de même de le préciser pour c eux que ça aurait pu induire en erreur :)
Dominique Marie wrote:
STOP !!! Grosse bêtise, le MVC prône la séparation de la logique de
traitement de celle de présentation. Ne pas confondre !!!
J'aurais pu rajouter "et de la logique de présentation", mais ça
n'illustrait pas mon propos. Merci tout de même de le préciser pour c eux
que ça aurait pu induire en erreur :)
STOP !!! Grosse bêtise, le MVC prône la séparation de la logique de traitement de celle de présentation. Ne pas confondre !!!
J'aurais pu rajouter "et de la logique de présentation", mais ça n'illustrait pas mon propos. Merci tout de même de le préciser pour c eux que ça aurait pu induire en erreur :)
Emmanuel Bourg
Nicolas Delsaux wrote:
Pas du tout, le design MVC sépare la vue du modèle et du contrôle ur. Or on trouve dans chacun de ces trois éléments des données et des traitements. Le cas typique d'applications Swing devrait suffir à te le démontrer. Dans une appli Swing, la vue contient des données, ainsi évidement que des méthodes, et il en va de même pour le modèle.
Dans le cas d'une application Struts par exemple le contrôleur est en charge de préparer les données qui seront ensuite envoyées à la v ue. Cette préparation peut représenter des traitements complexes qui dépassent la responsabilité des objets du modèle. C'est là que le s managers peuvent apparaître, ils centralisent ces traitements et permettent leur réutilisation. Quelle autre approche utiliser sinon ?
Nicolas Delsaux wrote:
Pas du tout, le design MVC sépare la vue du modèle et du contrôle ur. Or
on trouve dans chacun de ces trois éléments des données et des
traitements. Le cas typique d'applications Swing devrait suffir à te le
démontrer. Dans une appli Swing, la vue contient des données, ainsi
évidement que des méthodes, et il en va de même pour le modèle.
Dans le cas d'une application Struts par exemple le contrôleur est en
charge de préparer les données qui seront ensuite envoyées à la v ue.
Cette préparation peut représenter des traitements complexes qui
dépassent la responsabilité des objets du modèle. C'est là que le s
managers peuvent apparaître, ils centralisent ces traitements et
permettent leur réutilisation. Quelle autre approche utiliser sinon ?
Pas du tout, le design MVC sépare la vue du modèle et du contrôle ur. Or on trouve dans chacun de ces trois éléments des données et des traitements. Le cas typique d'applications Swing devrait suffir à te le démontrer. Dans une appli Swing, la vue contient des données, ainsi évidement que des méthodes, et il en va de même pour le modèle.
Dans le cas d'une application Struts par exemple le contrôleur est en charge de préparer les données qui seront ensuite envoyées à la v ue. Cette préparation peut représenter des traitements complexes qui dépassent la responsabilité des objets du modèle. C'est là que le s managers peuvent apparaître, ils centralisent ces traitements et permettent leur réutilisation. Quelle autre approche utiliser sinon ?
MacTotoche
Emmanuel Bourg wrote:
Tu ne peux pas demander à ton modèle de gérer tous les processus auxquels il peut participer, par exemple la persistance. AhMéSi !
Typiquement c'est la classe qui sait comment s'écrire et se lire. cf plus bas.
Il est absurde de charger l'objet avec toutes les responsabilités possibles. AhNon !
Il ne s'agit pas de charger la classe de responsabilités inutiles, mais toujours de limiter la visibilité et donc les risques en ne laissant connaître aux autres que le minimum, idéalement seulement des méthodes (et puis quelques constantes, et puis finalement aussi quelques variables parce que ça va faire plus court, mais juste une fois alors... :-) ).
C'est là que le *C*ontrôleur intervient. D'accord !
Il dispatche lors d'actions sur plusieurs objets, exemple la persistance, mais c'est quand-même le Modèle qui reste l'unité de cohérence des données.
Par contre l'autre extrême consistant à sortir les méthodes de l'objet pour ne laisser que les données n'est pas non plus enviable, on ne gagne pas grand chose par rapport à un simple struct C effectivement si ce n'est l'héritage. L'objet doit conserver les méthodes suffisantes pour gérer son état et faciliter sa manipulation élémentaire MmmmOui.
Et même un peu plus que ça dans mon idée, la classe devant absorber (au moins) toutes les méthodes qui accèdent à des variables d'instance.
Oui on arrive quand même à parler de choses intéressantes sur un troll PHP/Java, c'est fort C'est le danger du troll insidieux. C'est pourquoi je vais arrêter de
le nourrir sur ce consensus /à peu près/ atteint.
-- Olivier This space for sale.
Emmanuel Bourg wrote:
Tu ne peux pas demander à ton modèle de gérer tous les processus
auxquels il peut participer, par exemple la persistance.
AhMéSi !
Typiquement c'est la classe qui sait comment s'écrire et se lire.
cf plus bas.
Il est absurde
de charger l'objet avec toutes les responsabilités possibles.
AhNon !
Il ne s'agit pas de charger la classe de responsabilités inutiles,
mais toujours de limiter la visibilité et donc les risques en ne
laissant connaître aux autres que le minimum, idéalement seulement des
méthodes (et puis quelques constantes, et puis finalement aussi
quelques variables parce que ça va faire plus court, mais juste une
fois alors... :-) ).
C'est là
que le *C*ontrôleur intervient.
D'accord !
Il dispatche lors d'actions sur plusieurs objets, exemple la
persistance, mais c'est quand-même le Modèle qui reste l'unité de
cohérence des données.
Par contre l'autre extrême consistant à
sortir les méthodes de l'objet pour ne laisser que les données n'est pas
non plus enviable, on ne gagne pas grand chose par rapport à un simple
struct C effectivement si ce n'est l'héritage. L'objet doit conserver
les méthodes suffisantes pour gérer son état et faciliter sa
manipulation élémentaire
MmmmOui.
Et même un peu plus que ça dans mon idée, la classe devant absorber
(au moins) toutes les méthodes qui accèdent à des variables d'instance.
Oui on arrive quand même à parler de choses intéressantes sur un troll PHP/Java, c'est fort
C'est le danger du troll insidieux. C'est pourquoi je vais arrêter de
Tu ne peux pas demander à ton modèle de gérer tous les processus auxquels il peut participer, par exemple la persistance. AhMéSi !
Typiquement c'est la classe qui sait comment s'écrire et se lire. cf plus bas.
Il est absurde de charger l'objet avec toutes les responsabilités possibles. AhNon !
Il ne s'agit pas de charger la classe de responsabilités inutiles, mais toujours de limiter la visibilité et donc les risques en ne laissant connaître aux autres que le minimum, idéalement seulement des méthodes (et puis quelques constantes, et puis finalement aussi quelques variables parce que ça va faire plus court, mais juste une fois alors... :-) ).
C'est là que le *C*ontrôleur intervient. D'accord !
Il dispatche lors d'actions sur plusieurs objets, exemple la persistance, mais c'est quand-même le Modèle qui reste l'unité de cohérence des données.
Par contre l'autre extrême consistant à sortir les méthodes de l'objet pour ne laisser que les données n'est pas non plus enviable, on ne gagne pas grand chose par rapport à un simple struct C effectivement si ce n'est l'héritage. L'objet doit conserver les méthodes suffisantes pour gérer son état et faciliter sa manipulation élémentaire MmmmOui.
Et même un peu plus que ça dans mon idée, la classe devant absorber (au moins) toutes les méthodes qui accèdent à des variables d'instance.
Oui on arrive quand même à parler de choses intéressantes sur un troll PHP/Java, c'est fort C'est le danger du troll insidieux. C'est pourquoi je vais arrêter de
le nourrir sur ce consensus /à peu près/ atteint.
-- Olivier This space for sale.
TestMan
Sans faire courrir de troll et pour faire ultra simple
PHP : interessant si tu compte réutiliser des modules existnat (style PHPNuke, phpBB & co ) Java : interessant si tu comptes créer une solution originale et performante s'integrant éventuellement dans un existant.
De façon générale la chrage initial PHP fait qu'il est plus véloce, mais Java monte largement plus facilement en charge.
Je trouve que PHP est super sympas pour plein de trucs, mais vraiment niveau architecture, ça tiens pas la route 2 seconde. (cf. clustering, loadballacing, messaging, integration systeme existant ,....)
Enfin, la tendance "yet another" de certains rodant autour de PHP n'est pas du meilleur présage question pérénité. Que le premier qui ne fait pas de perl me tire dessus ;-)
Si tu es fan de l'opensource, regarde Tomcat et JBoss.
A noter une nouvelle qui fait son bruit dans le landernau : Apache lance un projet Opensource J2EE http://apache.slashdot.org/apache/03/08/05/1848259.shtml?tid8&tid6&tid6
Pour le reste, c'est à toi de choisir: simplicité ou fonctionalités.
A+
-SLK
"Eric Alquier" a écrit dans le message de news:bggav6$17r$
Bonjour,
Je m'interroge sur les avantages et inconvénients de chacun des deux langages Java et PHP, ou Javascript/PHP
En effet, je souhaite créer un site intéractif connecté à un base de donnée
(MySQL certainement), mais lequel choisir ?
Merci pour vos infos et conseils.
cordialement,
Eric A. ()
Sans faire courrir de troll et pour faire ultra simple
PHP : interessant si tu compte réutiliser des modules existnat (style
PHPNuke, phpBB & co )
Java : interessant si tu comptes créer une solution originale et performante
s'integrant éventuellement dans un existant.
De façon générale la chrage initial PHP fait qu'il est plus véloce, mais
Java monte largement plus facilement en charge.
Je trouve que PHP est super sympas pour plein de trucs, mais vraiment niveau
architecture, ça tiens pas la route 2 seconde.
(cf. clustering, loadballacing, messaging, integration systeme existant
,....)
Enfin, la tendance "yet another" de certains rodant autour de PHP n'est pas
du meilleur présage question pérénité. Que le premier qui ne fait pas de
perl me tire dessus ;-)
Si tu es fan de l'opensource, regarde Tomcat et JBoss.
A noter une nouvelle qui fait son bruit dans le landernau :
Apache lance un projet Opensource J2EE
http://apache.slashdot.org/apache/03/08/05/1848259.shtml?tid8&tid6&tid6
Pour le reste, c'est à toi de choisir: simplicité ou fonctionalités.
A+
-SLK
"Eric Alquier" <eric.alquier.berry@wanadoo.fr> a écrit dans le message de
news:bggav6$17r$2@news-reader1.wanadoo.fr...
Bonjour,
Je m'interroge sur les avantages et inconvénients de chacun des deux
langages Java et PHP, ou Javascript/PHP
En effet, je souhaite créer un site intéractif connecté à un base de
donnée
Sans faire courrir de troll et pour faire ultra simple
PHP : interessant si tu compte réutiliser des modules existnat (style PHPNuke, phpBB & co ) Java : interessant si tu comptes créer une solution originale et performante s'integrant éventuellement dans un existant.
De façon générale la chrage initial PHP fait qu'il est plus véloce, mais Java monte largement plus facilement en charge.
Je trouve que PHP est super sympas pour plein de trucs, mais vraiment niveau architecture, ça tiens pas la route 2 seconde. (cf. clustering, loadballacing, messaging, integration systeme existant ,....)
Enfin, la tendance "yet another" de certains rodant autour de PHP n'est pas du meilleur présage question pérénité. Que le premier qui ne fait pas de perl me tire dessus ;-)
Si tu es fan de l'opensource, regarde Tomcat et JBoss.
A noter une nouvelle qui fait son bruit dans le landernau : Apache lance un projet Opensource J2EE http://apache.slashdot.org/apache/03/08/05/1848259.shtml?tid8&tid6&tid6
Pour le reste, c'est à toi de choisir: simplicité ou fonctionalités.
A+
-SLK
"Eric Alquier" a écrit dans le message de news:bggav6$17r$
Bonjour,
Je m'interroge sur les avantages et inconvénients de chacun des deux langages Java et PHP, ou Javascript/PHP
En effet, je souhaite créer un site intéractif connecté à un base de donnée
