Discussion :

[ouedmouss]

Bonjour.
Je suis un développeur java habitué aux technologie jsf, hibernate, ejb.
Dans ces technologies la separation des couches est clairement bien définies et la maintenance se voit facilitée.

Actuellement, je dois developper une application ou les contraintes sont database oracle, forms 10g (tout l'arsenal oracle).
Après 1 mois de travail sur ces outils, mon sentiment (et je dis bien mon sentiement), c'est que ces outils nous ramènent tres en arriere sur toutes les bonnes pratique de conception :
-Pas d'implementation véritable du concept d'objet
-Aucune separation des couche (quoi qu'on peut regrouper nos elements en procedure, mais cela reste du procedural qui a montre ces limites).

En gros on retombe dans l'ere visual basic.

J'ai beaucoup travaillé sur jdeveloper et je tire un chapeau a oracle qui a quant meme fait un travail énorme (et proposé gratuitement en plus).

-Pourquoi vouloir conserver cet outils
-la migration web via les applets est il un bon modele
-Peut on véritable faire un séparation de couche avec forms 10g (Module de persistance, logique metier, module d'adaptation si necessaire, presentation)

Deja merci de contribuer a cette discussion

[orafrance]

en fait c'est simplement historique je pense. Oracle ne peut pas se permettre d'abandonner une techno qui existe chez de nombreux client. Par ailleurs, l'architecture n-tiers est bien présente et l'objet aussi même si c'est beaucoup plus encapsuler ce qui permet d'être plus accessible aux informaticiens de gestion surement moins compétent en java.

Par ailleurs, cette techno marche plutôt bien et est une concurrence tout à fait valable aux technos purement java.

Pourquoi donc vouloir tout mettre sous java ? Le client-serveur est bel et bien fini mais les solutions sont multiples et tout à fait pérennes à mon avis

[plaineR]

Je rajouterai que les temps de développement ne sont pas les mêmes ni la complexité du langage. Forms est un L4G qui permet à des personnes ayant des connaissances techniques limitées de faire des écrans simples grâce aux système des wizzard. Enfin forms permet de corriger et d'améliorer des écrans générés avec designer.

C'est dingue comme les développeurs java pensent que seul java est bien (comme les développeurs C, il y a quelques années). Certes java a de nombreux avantages, mais si les autres langages existent et sont utilisés, c'est qu'ils ont aussi leurs avantages.

[ouedmouss]

Je ne parle pas de java . Mais de best practice.
Aujourd'hui, la plateforme .Net de Microsoft (meme si je ne l'aime pas beaucoup) évolue et fait des efforts remarques a mon sens.

On est oblige actuelleemnt lorsqu'il ya une peitite modification dans notre base de données de vraiment recherche dans l'application la ou il faut impacter.

Selon moi, point besoin d'etre développeur java comprendre

Et puis sérieusement, Une application lié comme un glue a une base de donnée est elle une bonne solution.

[orafrance]

surtout que le java c'est pas le plus pratique pour requêter une base... même hibernate est loin d'être infaillible

[c.langlet]

Je suis nouveau dans le dev forms (nous sommes en plein re-developpement de nos appli sous forms), et je pense qu'un developpeur de gestion va plus facilement apréhender forms que java qui est beaucoup plus subtil.
La simplicite (relative) du pl/sql et idéal pour le developpement d'application de gestion.
Java n'est pas un choix de prime abord qui me viendrais à l'esprit pour ecrire un erp, du moins c'est mon avis.

[SheikYerbouti]

...<<Bonjour.
Je suis un développeur java habitué aux technologie jsf, hibernate, ejb.
Dans ces technologies la separation des couches est clairement bien définies et la maintenance se voit facilitée.>>...

Dans ce cas la question ne pose même pas. Jetez-vous sur JDeveloper.

[plaineR]

Je ne parle pas de java . Mais de best practice.
Aujourd'hui, la plateforme .Net de Microsoft (meme si je ne l'aime pas beaucoup) évolue et fait des efforts remarques a mon sens.

En terme de compatibilité entre les versions, je préfère de loin forms à Microsoft. Après si forms en lui-même n'évolue pas pas beaucoup en terme de fonctionnalité, l'intégration aisée de java corrige en partie cette faiblesse.

On est oblige actuelleemnt lorsqu'il ya une peitite modification dans notre base de données de vraiment recherche dans l'application la ou il faut impacter.

Peut-être que votre appli est mal documentée (voire mal conçue). Personnellement je bosse sur une appli qui fonctionne depuis plus de 10 ans avec forms, qui a connu de nombreuses évolutions tant dans les modules que dans la base de données et nous n'avons jamais eu de soucis de cet ordre.

Et puis sérieusement, Une application lié comme un glue a une base de donnée est elle une bonne solution.

Si la stratégie est de ne travailler qu'avec les bases oracle, je dirai que c'est un énorme avantage, puisque forms s'intègre complètement et très facilement avec la base. Je suis loin d'être un spécialiste java, mais je vois qu'il est quand même beaucoup plus simple de requêter une base oracle avec forms qu'avec java.

[orafrance]

On est oblige actuelleemnt lorsqu'il ya une peitite modification dans notre base de données de vraiment recherche dans l'application la ou il faut impacter.

Il ne faut pas mettre sur le dos de la techno un manque de documentation et de bonnes pratiques

Et puis sérieusement, Une application lié comme un glue a une base de donnée est elle une bonne solution.

Oui... si c'est une application qui a pour but de lire, modifier et supprimer des données... dans une base de données

[orafrance]

Je suis loin d'être un spécialiste java, mais je vois qu'il est quand même beaucoup plus simple de requêter une base oracle avec forms qu'avec java.

Sans compter les erreurs trop souvent faites par les développeurs java qui ne ferme pas leur curseur ou gére des transactions de manière pour le moins anarchique... c'est souvent un cauchemar pour le DBA