Pourquoi utiliser Oracle Application Express pour une application web ?

Question

Je crois que nous allons passer à Oracle Apex pour les développements futurs. J'ai lu à propos d'Oracle Apex sur Wikipedia et de ses avantages et inconvénients. Il me semble que les inconvénients l'emportent sur les avantages mais peut-être que je me trompe. J'ai l'impression qu'Oracle Apex est destiné aux administrateurs de bases de données avec peu ou pas de connaissance en programmation pour configurer rapidement une application web, un peu comme MS Access pour les non-programmeurs.

Si vous avez de l'expérience avec Oracle Apex, pouvez-vous partager vos impressions? D'après l'article de Wikipedia, il semble que vous n'ayez pas besoin de connaître un langage de programmation mais simplement le PL/SQL?

Oracle Apex est-il évolutif? Peut-il gérer un trafic de la taille de celui de Facebook?

Après avoir travaillé pendant près de deux ans sur Oracle Apex 3.2, je peux affirmer en toute sécurité que je le déteste et je ne vois pas pourquoi quelqu'un voudrait créer une application web/page sur un navigateur, en PL/SQL sans possibilité de contrôle de version.

Answer 1

Veuillez noter que mes expériences concernent APEX 2.x-3.0.

J'ai utilisé Apex pour quelques applications internes sur une période de 12 mois, mais j'ai finalement abandonné pour ASP.NET.

Certains évangélistes d'Oracle affirment qu'il est possible de créer du contenu hautement dynamique au niveau des frameworks plus populaires tels que ASP.NET/J2EE. Techniquement, c'est vrai, mais c'est aussi vrai que vous pourriez traverser l'Atlantique dans un canoë monoplace. Si vous êtes tenté de vous lancer dans un projet APEX, même de complexité modérée, je vous suggère de regarder l'exemple APEX d'un forum de discussion simple. Comparez-le à un exemple de forum de discussion ASP.NET MVC ou une implémentation RoR.

Cela étant dit :

Les bons points

• Incroyablement facile de générer une application web respectable avec des saisies de données CRUD de base, des rapports simples et de peupler avec des données. Si vous êtes l'informaticien chargé de consolider le fouillis de bases de données Excel/Access d'une entreprise dans un environnement DB/web central, vous devriez jeter un coup d'œil à APEX, il est très adapté à cette tâche. Si vous prévoyez que la portée évolue vers quelque chose de même de complexité modérée, je passerais directement à un framework plus flexible.

• Si vous êtes un expert DBA/PLSQL mais n'avez aucune expérience en développement web traditionnel, vous serez bien préparé pour exposer la logique métier existante dans une application web sans avoir à jongler avec HTML/CSS/JavaScript si vous ne le souhaitez pas.

• Le forum de support d'APEX regorge d'informations et est bien géré par des développeurs APEX.

Les points négatifs

Mes expériences avec Apex ont commencé à décliner lorsque les applications sont passées au-delà des saisies de données CRUD et ont nécessité des comportements plus dynamiques et événementiels.

• L'interface utilisateur basée sur le Web n'est pas cool. Le débogage est douloureux.

• Le contrôle de version ? Qui en a besoin ?

• Quand vous (inévitablement) avez besoin de faire quelque chose en dehors de la portée limitée du framework, vous devrez mettre les mains dans le cambouis avec PL/SQL. Écrire de la logique métier contre la base de données est bien, mais générer du HTML à partir de procédures PL/SQL semblait malheureusement archaïque en 2007.

• Compte tenu du grand nombre d'endroits sournois où vous pouvez cacher la logique de page et de redirection, le flux du programme est à la fois difficile à visualiser et pas naturellement propice à un code modulaire, séparable et réutilisable. Les développeurs OOP ne seront pas impressionnés. Il est possible d'avoir des applications bien structurées et maintenables avec APEX mais c'est plus difficile que nécessaire. Cela n'a rien à voir avec le modèle MVC.

• Nombre inacceptable de bugs de framework dans les versions que j'ai utilisées. J'espère que cela s'est amélioré avec les versions récentes, mais le paradigme d'intégration de l'IDE dans la plateforme APEX elle-même m'a causé certaines des plus sombres et destructrices sessions de débogage de ma vie. Par exemple, j'essayais de reproduire un bogue intermittent qui faisait perdre les données de session à un utilisateur. En utilisant la fenêtre d'informations sur la session, j'ai vu qu'occasionnellement les données de session changer soudainement. J'ai passé 2 jours à essayer de trouver l'erreur dans mon code sans succès. Près du délire, j'ai remarqué par pur hasard que je pouvais reproduire des données de session erronées dans la fenêtre de débogage mais l'application elle-même n'entrait pas dans un état d'erreur. Mon cœur a coulé quand j'ai réalisé ce qui se passait. Oracle a ensuite confirmé que j'avais trouvé un bogue dans APEX qui faisait que la fenêtre d'information sur la session me montrait occasionnellement des données d'une session antérieure. J'avais passé 2 jours à déboguer un bogue lié à la session avec une fenêtre de débogage de session buggy. C'était la dernière application Apex que j'ai construite.

• PL/SQL n'est pas et ne sera jamais la prochaine grande chose en développement web. Après avoir travaillé avec APEX un certain temps, j'ai réalisé que cela ne m'aiderait pas à devenir un meilleur développeur web. Maîtriser APEX, c'est vraiment maîtriser le PL/SQL. C'est bien si vous prévoyez de vous concentrer sur la technologie Oracle, mais soyez conscient que APEX est tellement tangente à la direction des technologies web principales que le jeu de compétences que vous pouvez emporter d'APEX vers d'autres frameworks web est minimal.

Si vous envisagez d'utiliser APEX pour fournir des saisies de données web simples et des rapports, cela vaut la peine d'y jeter un œil. Si vous cherchez une alternative à .NET/JAVA/PHP pour du contenu web dynamique et des interactions riches avec l'interface utilisateur, je vous conseille de regarder ailleurs.

Answer 2

J'ai lu cette page avec grand intérêt. Notre équipe de développement utilise Apex depuis environ 2 ans maintenant, et j'aimerais résumer notre expérience.

Pour la construction d'applications CRUD de base, Apex est vraiment excellent. En fait, je vous recommande de l'essayer vous-même. Nous avons rencontré quelques difficultés mineures initiales pour le configurer, mais celles-ci semblent avoir été résolues dans la version 3.2.

Le bon

• Idéal pour les applications simples. Si votre application va devenir plus complexe, envisagez une solution alternative.
• Les modèles intégrés font que votre application ait l'air assez professionnelle (bien que certains puissent contester cela).
• Un bon forum de support et une communauté active, avec beaucoup de personnes prêtes à vous aider.
• Des commandes intégrées exceptionnelles. J'adore les graphiques et les rapports (mais voir ci-dessous).

Le mauvais

• Le débogueur est abominable. Si vous avez utilisé Visual Studio (et même des versions anciennes de Microsoft Access), vous serez décontenancé par le débogueur. Pas de points d'arrêt, des messages de débogage qui sortent en liste, devoir afficher manuellement les messages de débogage à l'écran. Horrible. La cause de nombreuses heures perdues à du support.

• Dès que votre application devient complexe ou nécessite une fonctionnalité avancée, vous devez recourir à Javascript, HTML / CSS, ce qui rend le débogage et le support encore plus compliqués (bien que vous puissiez utiliser des outils comme Firebug ou Visual Studio pour vous aider).

• Nous avons rencontré des bogues d'état de session inexpliqués et des feuilles de style devenant "détachées" de l'application sans explication - pour n'en nommer que quelques-uns.

• Le support d'applications inconnues peut être difficile, car il peut être difficile de suivre la logique des pages sans un bon débogueur. Et je ne crois pas à la réponse standard du type "eh bien - les applications devraient être mieux codées". Parce que dans le monde réel, elles ne le sont pas - surtout quand vous utilisez un entrepreneur.

• Les rapports sont beaux mais pas très utiles si vous ne pouvez pas les imprimer ou les exporter en PDF. Bien sûr, vous pouvez investir dans un serveur de reporting, au final nous avons utilisé une autre solution.

En conclusion

Je dirais d'utiliser Apex sans hésitation pour des applications CRUD simples. Pour toute application de plus grande complexité, optez pour .Net ou Java. Je ne tiendrais pas compte de l'article Wiki sur Apex car il est très biaisé. Remarquez comment la mention "difficile à déboguer" (à mon avis le plus gros échec) a été effacée de l'article.

Autre chose de très prudent à noter est l'affirmation absurde que vous pouvez rapidement convertir des bases de données Access directement en Apex. Oui, cela fonctionnera si votre base de données Access est très, très simpliste. Pour tout ce qui est modérément complexe, oubliez ça, comme nous l'avons constaté.

Nous ne l'utiliserions certainement pas pour des applications orientées web, seulement en interne. Il y a tout simplement trop de difficultés à faire des choses que vous tiendriez pour acquises dans, disons, .Net. Je sais qu'il y a des sites comme AskTom, mais ils ne sont pas exactement complexes. Allons-nous voir le prochain Facebook sur ce logiciel ? Je ne pense pas - bien que je sois sûr que quelqu'un lisant ceci va tenter sa chance.

Apex est résumé dans un commentaire précédent - les managers voient les démos, et adhèrent rapidement, convaincus d'avoir trouvé une solution miracle qui réduira les temps de développement. J'ai eu des managers qui m'appelaient et me disaient, nous avons besoin d'une application de base de données avec 40 tables à construire en une semaine en Apex s'il vous plaît - voilà à quel point le mythe s'est propagé. La réalité est quelque peu différente. Oui certaines choses sont plus rapides, nettement plus rapides, mais vous perdrez du temps dans d'autres domaines - débogage, support et personnalisation.

Évidemment, vous êtes le mieux placé pour décider par vous-même. Installez-le, essayez-le, vous pourriez l'apprécier. Mais ne vous laissez pas tromper par des affirmations de temps de développement rapide avant de l'avoir bien testé sur une application réaliste.

Answer 3

Je suis impliqué dans un énorme projet de migration d'une application Oracle Forms de 5000 modules vers APEX. C'est une utilisation extrême d'APEX, mais cela fonctionne très bien. C'est un mythe complet que APEX convient uniquement aux petites applications internes développées par les DBA, les stagiaires ou les utilisateurs finaux : cela convient certainement à ceux-là aussi (et plus que la plupart des autres outils), mais cela peut également être utilisé pour construire des applications extrêmement sophistiquées.

Pour construire une application sophistiquée (plutôt qu'une application APEX par défaut), vous aurez besoin de quelqu'un dans l'équipe ayant des compétences en Javascript et quelqu'un ayant des compétences en CSS. Mais la plupart des développeurs auront juste besoin de PL/SQL au départ.

Est-ce scalable ? Oui : probablement plus scalable que la plupart des autres solutions ! APEX ajoute très peu d'overhead au serveur de base de données, et seul le serveur d'application le plus minimal est requis. Taille de "Facebook" ? Je ne sais pas avec certitude mais je ne vois pas pourquoi pas, en supposant que vous ayez une base de données Oracle sur une machine assez grande et puissante pour gérer les volumes de données et de transactions de taille "Facebook". Comme pour tout projet Oracle, la scalabilité est principalement entravée par de mauvais designs de base de données et de SQL mal écrit, et non par l'outil. Cependant, peu de gens se retrouvent à construire des systèmes de taille "Facebook" : êtes-vous ?

Answer 4

APEX est un framework qui utilise la base de données et PL/SQL pour produire des pages web. Si vous pouvez déterminer ce que la sortie vers le navigateur devra être, vous pouvez la créer dans APEX. Si vous trouvez une partie du framework inhibant, vous pouvez écrire des procédures PL/SQL et les exposer directement au serveur web tout en profitant de la sécurité, du journalisation, de l'état de session, etc. que le système APEX gère pour vous.

Vous devriez connaître PL/SQL, SQL, HTML, JavaScript et CSS. Bien sûr, l'interface ressemble à une grande application de saisie de données, mais les données que vous saisissez seront principalement des extraits de code dans chacun de ces langages.

Il s'adapte aussi bien que la base de données. Il utilise généralement Apache comme serveur web mais est uniquement utilisé pour servir des fichiers statiques et renvoyer les requêtes à la base de données, où les pages web sont créées par le code PL/SQL dans le schéma APEX. Vous pouvez utiliser AJAX pour réduire la taille du trafic qui circule dans le tuyau. Vous pouvez définir des mises en cache pour des éléments spécifiques, des listes, des régions de page, des pages, etc.

Étant donné que la plupart des choses sont assez simples à réaliser avec le framework, il y aura naturellement des choses un peu plus compliquées à faire dans le cadre du framework. L'exemple de colorisation donné ci-dessus pourrait être quelque chose que vous faites avec CSS ou peut-être que vous devrez recourir à des instructions d'impression pour produire la sortie dont vous avez besoin. L'idée est d'apprendre comment le framework facilite la vie, puis quand vous atteignez une limite, vous pouvez facilement recourir à des méthodes plus directes.

En venant de VB.Net, vous regretterez le débogage étape par étape et le glisser-déposer. Vous ne regretterez jamais le fait qu'une partie du cycle de vie de la page va effectuer un bind et réinitialiser les valeurs auxquelles vous avez lié un objet dans une autre partie de la page.

Bonne chance.

Greg

Answer 5

Je suis un DBA et je n'ai jamais eu à programmer avec APEX ou récemment quoi que ce soit d'autre (à part quelques scripts bash et des scripts SQL personnalisés à des fins d'administration) car mon travail est loin du développement d'applications (à part être un casse-pieds pour les développeurs). Bien sûr, mon expérience est plutôt du côté développeur et je crois fermement qu'APEX est l'avenir pour les programmes centrés sur les données basés strictement sur Oracle.

Maintenant, le mot-clé ici est centré sur les données, car je suis en désaccord avec de nombreux autres DBAs qui pensent que toutes les applications sont centrées sur les données (vous savez, ce genre de DBAs qui pensent encore que ODBC signifie ORACLE Database Connectivity). Bien sûr, toutes les applications impliquent des données mais sont-elles toutes centrées sur les données? J'en doute, tout comme je doute qu'APEX sera jamais utilisé pour le traitement d'images ou des applications de jeux mobiles. Cependant, malgré tout le battage médiatique autour des RIA et du Web 2.0, la réalité est que la plupart des entreprises qui nous entourent recherchent désespérément ces bonnes vieilles applications centrées sur les données et Oracle est la meilleure base de données disponible et je peux vous assurer qu'Oracle et APEX peuvent gérer beaucoup plus que l'évolutivité de Facebook, à condition bien sûr que vous investissiez la même somme d'argent que les gars de Facebook dans l'infrastructure sous-jacente.

À propos, je déteste aussi le design des thèmes APEX d'Oracle (une UI horriblement non professionnelle, imaginez cela comme UI principale pour une banque ou une compagnie aérienne), des capacités limitées (bien que cela semble sur le point de changer à l'avenir), et bien d'autres problèmes (rapports PDF professionnels sans devoir payer une licence pour BI Publisher Enterprise ??) mais surtout le marketing d'APEX en tant que substitut d'Access ou Excel parce que cela donne une impression négative, comme si c'était pour les enfants, et je peux vous assurer, mon ami, je ne laisserais jamais des enfants toucher mes bases de données :)

Vous voyez, Oracle a un bijou appelé PL/SQL qui a été perfectionné au fil des ans pour gérer les données de manière bien plus intuitive que n'importe quel autre langage. Or ce bijou se meurt avec le déclin lent de Forms/Reports et je suis convaincu qu'aucun jeune diplômé ne prendra la peine d'apprendre strictement pour les procédures stockées en base de données (il suffit de regarder la guerre acharnée entre les développeurs Java et .Net et vous comprendrez qu'une fois que vous touchez les accolades {} tout le reste devient une hérésie). Hélas, pour des milliers d'excellents développeurs en PL/SQL, APEX reste le seul refuge où ils peuvent rester productifs et développer des applications centrées sur les données exceptionnelles et sans APEX, PL/SQL deviendra sûrement le prochain COBOL. C'est pourquoi la communauté PL/SQL incitera Oracle à transformer APEX en une plateforme de première importance, bien plus puissante que ce que nous voyons aujourd'hui. Ou sinon, adieu PL/SQL et à vous les accolades (au fait ce n'est jamais une mauvaise idée d'essayer au moins différentes technologies quand vous êtes développeur, au moins vous avez une idée pourquoi ce n'est pas forcément mieux ailleurs).