Ca fait de l'ajax, c'est mvc, il y a une interface en ligne de commande. Passer ces trucs super bateaux, le reste est franchement différent.
C'est vrai.
Perso j'associerai beaucoup plus symfony aux frameworks java (config séparée du code, génération de la couche orm statique, peu de "magie" et beaucoup de cadre) qu'à Ror (totalement dynamique, peu ou pas de config, beaucoup de magie dans les comportements ...)
Je ne suis plus d'accord là, à vrai dire je vais défendre un peu symfony.
Tout dépend de quel coté on se place, il y a un peu deux mondes qui s'affrontent à coup de troll : celui de ceux qui maitrisent leurs bases et ceux qui maitrisent le code. Un petit tour d'horizon totalement pas exhaustif :
- D'un coté, on parle de pérénité des données, contraintes sur les tables champs etc, maîtrise de la cohérence toussa et l'interface doit s'adapter à la base.
- De l'autre on peut parler d'environnements et applications rapides à developper, d'abstraction de la base, de la gestion des contraintes et cohérence des données depuis les couches applicatives, de non multiplication des languages, etc.
Moi, je cherche quelque chose de souple, permettant de jouer sur les deux tableaux et c'est là que je ne suis plus d'accord avec toi.
RoR t'impose bel un bien un cadre dont on peut trés peu s'affranchir : c'est la fameuse règle "convention plutôt que configuration". Si tu as déjà une base de donnée existante, cette règle devient plutôt handicapante...
Ce que j'ai trouvé de bien avec symphony (et les projets qu'il a fait naître autour), c'est justement qu'il te permet d'utiliser une base existante, qu'il va aller fouiner trés loins dans celle-ci pour en déterminer l'architecture et les contraintes et te produire une fameuse couche orm statique.
MAIS, cette couche orm statique, tu n'y touche pas. Les modifications et ajouts que tu apportes (et c'est l'esprit de tout le framework, pas seulement pour la couche orm) tu le fait dans des classes héritiaires qui elles sont conservées d'une génération de l'orm à l'autre.
Bref, Symphony pour moi, c'est beaucoup plus de souplesse, une maitrise du code et de la base.
Maintenant, il est bien connu qu'un framework dépassera rarement les 80/90% du travail avec toutes les outils qu'il t'apporte...C'est le reste qui te posera problème et prendra le plus de temps de travail...
[^] # Re: Mes impressions
Posté par ioguix . En réponse au journal J2EE vs RoR vs Python. Évalué à 2.
C'est vrai.
Je ne suis plus d'accord là, à vrai dire je vais défendre un peu symfony.
Tout dépend de quel coté on se place, il y a un peu deux mondes qui s'affrontent à coup de troll : celui de ceux qui maitrisent leurs bases et ceux qui maitrisent le code. Un petit tour d'horizon totalement pas exhaustif :
- D'un coté, on parle de pérénité des données, contraintes sur les tables champs etc, maîtrise de la cohérence toussa et l'interface doit s'adapter à la base.
- De l'autre on peut parler d'environnements et applications rapides à developper, d'abstraction de la base, de la gestion des contraintes et cohérence des données depuis les couches applicatives, de non multiplication des languages, etc.
Moi, je cherche quelque chose de souple, permettant de jouer sur les deux tableaux et c'est là que je ne suis plus d'accord avec toi.
RoR t'impose bel un bien un cadre dont on peut trés peu s'affranchir : c'est la fameuse règle "convention plutôt que configuration". Si tu as déjà une base de donnée existante, cette règle devient plutôt handicapante...
Ce que j'ai trouvé de bien avec symphony (et les projets qu'il a fait naître autour), c'est justement qu'il te permet d'utiliser une base existante, qu'il va aller fouiner trés loins dans celle-ci pour en déterminer l'architecture et les contraintes et te produire une fameuse couche orm statique.
MAIS, cette couche orm statique, tu n'y touche pas. Les modifications et ajouts que tu apportes (et c'est l'esprit de tout le framework, pas seulement pour la couche orm) tu le fait dans des classes héritiaires qui elles sont conservées d'une génération de l'orm à l'autre.
Bref, Symphony pour moi, c'est beaucoup plus de souplesse, une maitrise du code et de la base.
Maintenant, il est bien connu qu'un framework dépassera rarement les 80/90% du travail avec toutes les outils qu'il t'apporte...C'est le reste qui te posera problème et prendra le plus de temps de travail...
mes 2¢ comme ils disent tous...