Discussion :

[bannik]

Bonjour,

Je doit effectuer une étude afin de faire les meilleurs choix technologiques quand au développement et à l'architecture d'une application WEB.
Bien sur, il y a des contraintes.

- l'application doit absolument être accessible, le plus possible. Ce qui veux dire que l'on ne souhaite pas utiliser tout ce qui est javascript, plugin, tout contrainte au niveau du client. On utilisera donc htm, css...
- L'application développée doit être "sécurisée" (injection sql etc...)
- Elle doit pouvoir être installée sur le plus de type de plateforme différentes (windows, linux, etc...)
- L'application doit supporter un très grand nombre de connexion
- Pouvoir créer et utiliser des webservices
- Le choix de la base doit être souple (pouvoir installer sur du oracle comme du mysql ou postgress), mais si on n'a pas le choix, on pourra en imposer une
- Notre équipe maitrise le mieux (par ordre descendant) PHP, Java, ASP, Flash / actionscript, powerbuilder, C#, VB

Nous pensons utiliser PHP, mais avant de prendre une décision, j'aimerai connaitre vos avis.

Peut/doit-on un framework? Lequel serait le plus adapté?
Quelle plateforme de dév utiliser (pour le moment nous utilisons éclipse)?
Y-a-t-il des outils qui pourraient nous aider a développer accessible?
Quelle architecture pour l'application (pour le moment, nous n'en utilisons pas, mais il semblerait que MVC soit à la mode (pourquoi?)?
Autre chose à prendre en compte?

Tous vos avis nous intéresse. Qu'en pensez vous?


Merci bcp.

[TekP@f]

Salut,

A lire tes contraintes, je vois plusieurs incohérences.

Bonjour,

Je doit effectuer une étude afin de faire les meilleurs choix technologiques quand au développement et à l'architecture d'une application WEB.

Ok, tu veux développer une application web.

- l'application doit absolument être accessible, le plus possible. Ce qui veux dire que l'on ne souhaite pas utiliser tout ce qui est javascript, plugin, tout contrainte au niveau du client. On utilisera donc htm, css...

Ne pas utiliser Javascript va te limiter énormément sur les aspects "Web 2.0" (contrôle/validation en temps réel des champs de saisie, effets à la mode style pagination ...). Et je n'ai pas de données en tête, mais le Javascript est installé sur une écrasante majorité des machines. Alors pourquoi s'en passer ? Au pire, prévois une gestion différente selon le poste client. Si le Javascript est supporté et s'il ne l'est pas.

- L'application développée doit être "sécurisée" (injection sql etc...)

Hé hé ! Contrainte de patron ça Comme ça, si t'es piraté un jour, c'est de ta faute, c'était précisé dans les specs que le site doit être sécurisé.
Pour sécuriser un site, il faut savoir 2 choses :
- 1 : ton site ne sera JAMAIS sécurisé à 100%. Ca se saurait s'il y avait une solution miracle
- 2 : c'est un gros travail de la part de l'architecte qui oriente la solution technique, du développeur qui évite des erreurs grossières (genre les injections SQL) et aussi (surtout ?) de l'administrateur.

- Elle doit pouvoir être installée sur le plus de type de plateforme différentes (windows, linux, etc...)

1ère incohérence. Appli web veut dire appli distante. Donc pas d'install. Tu peux peut-être parler de navigateur supporté ?

- L'application doit supporter un très grand nombre de connexion
- Pouvoir créer et utiliser des webservices

ok

- Le choix de la base doit être souple (pouvoir installer sur du oracle comme du mysql ou postgress), mais si on n'a pas le choix, on pourra en imposer une

2ème incohérence. Une application web est hébergée sur un serveur. Donc pourquoi installer une base sur le poste client ? La base est installée sur le serveur et puis c'est tout.
Au lieu d'application web, tu ne parlerais pas d'une application lourde installée sur un poste client et qui communique avec un serveur ?

- Notre équipe maitrise le mieux (par ordre descendant) PHP, Java, ASP, Flash / actionscript, powerbuilder, C#, VB

Up to you. Vous maîtrisez mieux PHP, partez sur le PHP alors. Flash et Actionscript seront peut-être nécessaires si vous avez des besoin d'animation.

Peut/doit-on un framework? Lequel serait le plus adapté?

Vous DEVEZ ! Réinventer la poudre ne sert à rien. Lequel, je ne sais pas. Je suis plus spécialisé Java. Tu demanderas sur le forum PHP.

Quelle plateforme de dév utiliser (pour le moment nous utilisons éclipse)?

Up to you aussi ! Eclipse est très bien, ne change pas.

Y-a-t-il des outils qui pourraient nous aider a développer accessible?

L'accessibilité est lié aux postes clients. Et le client utilise des browsers pour voir ton application web. C'est-à-dire HTML/JS/CSS. Donc accessibilité PHP ne veut rien dire.
Par contre, pour le Javascript, il existe des frameworks pour rendre ça corssbrowser (style JQuery).

Quelle architecture pour l'application (pour le moment, nous n'en utilisons pas, mais il semblerait que MVC soit à la mode (pourquoi?)?

Tout dépend de tes moyens, du volume du site ... A te lire, il s'agit d'un gros projet. Donc oui, utilise un design pattern (c'est le mot exact). MVC est effectivement le + répandu. C'est celui que j'utilise également. Pourquoi ? Tu t'en rendras compte en l'utilisant. Ca permet de bien séparer les choses.
http://fr.wikipedia.org/wiki/Modèle-Vue-Contrôleur

Tous vos avis nous intéresse. Qu'en pensez vous?

J'en pense que toutes ces questions sont prématurées.
C'est pour faire quoi cette appli ? Si tu peux utilise déjà des outils existants (CMS, CRM, portail ...). En général, la solution technique découle du besoin. Là, tu n'expliques pas le besoin. Donc c'est difficile de juger les choix techniques.

A+ et bon courage.

[bannik]

En premier lieu, merci pour ta réponse

Je vais essayer d'éclaircir plusieurs points.

Tout dépend de tes moyens, du volume du site ... A te lire, il s'agit d'un gros projet.

C'est en effet un gros projet, plusieurs dizaines (voir centaine) de millier d'utilisateur.

Ne pas utiliser Javascript va te limiter énormément sur les aspects "Web 2.0" (contrôle/validation en temps réel des champs de saisie, effets à la mode style pagination ...). Et je n'ai pas de données en tête, mais le Javascript est installé sur une écrasante majorité des machines. Alors pourquoi s'en passer ? Au pire, prévois une gestion différente selon le poste client. Si le Javascript est supporté et s'il ne l'est pas.

En effet, 5% des utilisateurs (en 2008) n'ont pas javascript d'activé. Malheureusement, le législateur a sortie une loi obligeant nos client a couvrir 100%
des utilisateurs potentiels (impossible à tenir, mais il faut quand même essayer). Dans les recommandations w3c, il est indiqué que les fonctionnalités
javascript doivent ne pas empêcher l'utilisation de l'application, de ce fait, ces fonctionnalités doivent, dans le cas ou elles sont nécessaires,
être suppléés par d'autre. Je vois les choses comme ca. De toute façon, les contrôles devront être aussi codés entièrement partie serveur,
un gain de temps (et donc d'argent) peut être fait si elles elle ne sont pas doublées par du javascript. On oublis aussi tout ce qui est evenements, tout ce qui est Document.write (non lu par les lecteurs d'écran comme JAWS pour les aveugles), Window.status, position du curseur, etc...
Tout ceci ajoute énormément de contraintes des test et enlève bcp d'intérêt au javascript. Du coup, je pense qu'il vaux mieux s'en passer dés la conception.

Hé hé ! Contrainte de patron ça Comme ça, si t'es piraté un jour, c'est de ta faute, c'était précisé dans les specs que le site doit être sécurisé.
Pour sécuriser un site, il faut savoir 2 choses :
- 1 : ton site ne sera JAMAIS sécurisé à 100%. Ca se saurait s'il y avait une solution miracle
- 2 : c'est un gros travail de la part de l'architecte qui oriente la solution technique, du développeur qui évite des erreurs grossières (genre les injections SQL) et aussi (surtout ?) de l'administrateur.

J'entends par là que par exemple, si on fait une requête sql genre "select toto from titi where tata='$var'", si on l'exécute directement, risque d'injection sql. Il me semblait que certains framework (ou bibliothèques) comme mdb2 de pear géraient ces risques injections. Ou bien le bind des variables. Qu'en est-il réellement?

1ère incohérence. Appli web veut dire appli distante. Donc pas d'install. Tu peux peut-être parler de navigateur supporté ?

je parle de l'installation du serveur web (apache, tomcat...) il mes semble que IIS est disqualifié sur autre chose que windows. Le problème est que certains client peuvent suivre nos recommandation sur le serveur web utilisé, mais d'autre peuvent nous l'imposer. D'ou l'intérêt (par exemple pour php) de pouvoir l'installer sur apache et IIS. Je voulait savoir ce qu'il en était des autres langages.

2ème incohérence. Une application web est hébergée sur un serveur. Donc pourquoi installer une base sur le poste client ? La base est installée sur le serveur et puis c'est tout.

Oui bien sur. Ce que je veux savoir, c'est si il est envisageable que mon application web tourne sur du oracle mais puisse être assez souple pour pouvoir être installée avec une autre base (par paramétrage)? Le problème viendrait principalement du sql qui diffère selon les bases. Est-ce que cela se fait? Pour d'autres application client-serveur, nous utilisent Oracle. Ca me parait un peut lourd et il est possible (probable) qu'on ne l'utilise pas pour cette appli web. Quel base conseiller qui puisse tenir une charge importante?

J'en pense que toutes ces questions sont prématurées.
C'est pour faire quoi cette appli ? Si tu peux utilise déjà des outils existants (CMS, CRM, portail ...). En général, la solution technique découle du besoin. Là, tu n'expliques pas le besoin. Donc c'est difficile de juger les choix techniques.

Moi pas.
Pour restituer un peut le contexte, il s'agit de la réécriture d'une application existante. Sur la précédente version, l'outil de développement (propriétaire) nous à été imposé (histoire commercialo-politique) sans avis des développeurs. Il s'est avéré que cet outils n'est pas du tout adapté pour l'application métier complexe et n'est pas du tout souple (ne serais-se que pour l'affichage, une journée pour tenter de faire des boutons radio verticaux...). Après quelques déboires, la direction a enfin réalisé les problèmes et envisage une réécriture (impossible de reprendre le code déjà fait a cause d'un moteur/framework de cette plateform de dev).
Cette fois on demande notre avis.
Cette application contient bcp de gestion métier et fait a la fois office de CRM, CMS et portail. Je connais quelques CRM et CMS, et il ne conviendront pas.
Elle sert à gérer des inscription, agendas, consulter et payer des factures, communiquer avec le client etc... Elle doit être modulable, souple quand a la présentation des données.
Les spec existent déjà, le besoin est bien défini on étudie la réalisation qui pourrait avoir lieu d'ici quelques mois. Savoir sur quoi on vas s'orienter dés maintenant vas nous permettre de nous préparer et c'est pas souvent que ca arrive.

Merci de ton aide.

[TekP@f]

En premier lieu, merci pour ta réponse

Pas de quoi

En effet, 5% des utilisateurs (en 2008) n'ont pas javascript d'activé. Malheureusement, le législateur a sortie une loi obligeant nos client a couvrir 100%
des utilisateurs potentiels (impossible à tenir, mais il faut quand même essayer). Dans les recommandations w3c, il est indiqué que les fonctionnalités
javascript doivent ne pas empêcher l'utilisation de l'application, de ce fait, ces fonctionnalités doivent, dans le cas ou elles sont nécessaires,
être suppléés par d'autre. Je vois les choses comme ca. De toute façon, les contrôles devront être aussi codés entièrement partie serveur,
un gain de temps (et donc d'argent) peut être fait si elles elle ne sont pas doublées par du javascript. On oublis aussi tout ce qui est evenements, tout ce qui est Document.write (non lu par les lecteurs d'écran comme JAWS pour les aveugles), Window.status, position du curseur, etc...
Tout ceci ajoute énormément de contraintes des test et enlève bcp d'intérêt au javascript. Du coup, je pense qu'il vaux mieux s'en passer dés la conception.

Ok, c'est votre choix. Je ne le partage pas mais vous semblez prendre la mesure du choix. Donc c'est très bien.
Juste une précision : les document.write et autres contrôles Javascript "classiques" de formulaire, ce n'est plus au goût du jour. Maintenant c'est contrôle Ajax à la saisie. Donc il y a un contrôle qui passe par le serveur et qui se contente de préciser si la saisie est bonne.
Mais tu ne parles que d'injection SQL. Il y a encore bcp d'autres méthodes de hack. Va falloir également y penser si tu veux être sécurisé 100%.

La meilleure sécurité : des sauvegardes !

J'entends par là que par exemple, si on fait une requête sql genre "select toto from titi where tata='$var'", si on l'exécute directement, risque d'injection sql. Il me semblait que certains framework (ou bibliothèques) comme mdb2 de pear géraient ces risques injections. Ou bien le bind des variables. Qu'en est-il réellement?

Passer par un ORM limite forcément ces risques mais pas à 0. Mais les frameworks PHP, je ne connais pas trop.
En Java, comme il y a un typage fort, on est protégé par ces injections. Il y a juste les String à faire attention. Pour ça, je double les quotes. Ca me protège des injections.
La meilleure méthode est de faire un CAST de chaque champ avant son utilisation. Tu peux trouver des docs à ce sujet sur le site.

je parle de l'installation du serveur web (apache, tomcat...) il mes semble que IIS est disqualifié sur autre chose que windows. Le problème est que certains client peuvent suivre nos recommandation sur le serveur web utilisé, mais d'autre peuvent nous l'imposer. D'ou l'intérêt (par exemple pour php) de pouvoir l'installer sur apache et IIS. Je voulait savoir ce qu'il en était des autres langages.

Ca veut dire que vous livrez un portail (ou un truc du genre, peu importe le mot) à des clients. Et ce portail vous l'installez sur le serveur du client. C'est bien ça ?

Concernant les config, PHP et Java peuvent très bien tourner sur Windows et Unix. Le vilain petit canard (.NET) nécessite IIS et donc Windows, donc pas d'Unix pour lui. Si tu dois t'adapter à un maximum de machines, vaut mieux éviter .NET alors. Tout le monde n'aura pas IIS.

Oui bien sur. Ce que je veux savoir, c'est si il est envisageable que mon application web tourne sur du oracle mais puisse être assez souple pour pouvoir être installée avec une autre base (par paramétrage)? Le problème viendrait principalement du sql qui diffère selon les bases. Est-ce que cela se fait? Pour d'autres application client-serveur, nous utilisent Oracle. Ca me parait un peut lourd et il est possible (probable) qu'on ne l'utilise pas pour cette appli web. Quel base conseiller qui puisse tenir une charge importante?

Oui ça se fait. Il faut passer par des ORM qui fournissent une abstraction du SGBD utilisé. Mais lourd dingue ton truc ! A part les CMS/portails Open Source qui doivent s'adapter à tout le monde, je ne vois pas pourquoi se fixer de telles contraintes.
Perso, j'utilise MySQL par facilité. Car peu de client. Postgres est très bien également.
J'aurais tendance à dire que MySQL est plus facile à manipuler mais offre moins de possibilités (comme les triggers, les procédures stockées ...). Tu as l'air d'avoir des gros besoins, donc je te conseille plutôt Postgres.


Sinon, quand je lis ton projet, en gros, c'est un ERP pour ta boite. C'est assez "classique". Chaque boite a tôt ou tard besoin de créer le sien. Mais du coup, je ne comprends pas ton besoin de déploiement sur des plateformes externes ?

[germaino_0]

my 2 cents :

- sécurité et flexibilité DB => ORM ( object relational mapping ) ( Doctrine, Propel ) avec Database Abstraction Layer ( Creole ).

- sécurité, qualité et flexibilité du code: un Framework MVC !
Top Frameworks PHP : Symfony , CakePHP.

En fait, il suffit d'utiliser un Framework. ca intègre tout ce qu'il faut, y compris l'ORM.

Pour la plateforme de dev: Eclipse (ou autre) , et ne pas oublier un système de gestion de version (SVN) !