Pourquoi utiliser Oracle Application Express pour application Web?
Je crois que nous passons à Oracle Apex pour un développement futur. J'ai lu sur Oracle Apex sur wikipedia et c'est pour et contre. Il me semble que le con l'emporte sur le pro mais peut-être que je me trompe. J'ai l'impression qu'Oracle Apex est pour DBA avec peu ou pas de connaissances en programmation pour configurer une application Web rapidement comme MS Access pour aucun programmeur.
Si vous avez une expérience de travail Oracle Apex, pouvez-vous partager votre opinion? D'après l'entrée de Wikipédia, il ne semble pas que vous ayez besoin de connaître un langage de programmation, mais juste le PL/SQL?
modifier: Oracle Apex est-il évolutif? Peut-il gérer du trafic comme la taille de Facebook?
edit: après avoir travaillé près de deux ans sur Oracle Apex 3.2. Je peux dire en toute sécurité que je déteste cela et je ne vois pas pourquoi quelqu'un voudrait créer une application/page Web sur un navigateur, pl/sql et aucun moyen de faire le contrôle de version.
Remercier.
Jack
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 je l'ai finalement vidé pour ASP.NET.
Certains évangélistes Oracle affirment qu'il est capable de créer un contenu hautement dynamique à égalité avec les cadres plus courants comme ASP.NET/J2EE. Techniquement, cela est vrai, mais techniquement, il est également vrai que vous pouvez traverser l'Atlantique en canoë pour un seul homme. Si vous êtes tenté de vous lancer dans un projet APEX de complexité même 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.
Ayant dit cela:
Le bien
Incroyablement facile à générer une application web respectable avec une saisie de données CRUD de base, un reporting simple et à la remplir avec des données. Si vous êtes l'informatique qui a été chargé de consolider le désordre d'Excel/Access dbs d'une entreprise dans un environnement central DB/Web, vous devriez jeter un coup d'œil à APEX, il convient très bien à cette tâche. Si vous vous attendez à ce que le champ d'application atteigne une complexité même modérée, je passerais directement à un cadre plus flexible.
Si vous êtes un gourou de DBA/PLSQL mais que vous n'avez aucune expérience du développement Web traditionnel, vous serez bien préparé pour exposer la logique métier existante dans une application Web sans vous bourrer de HTML/CSS/JavaScript si vous ne le souhaitez pas.
Le forum de support APEX a une tonne d'informations et est bien équipé par les développeurs APEX.
Le mauvais
Mon expérience avec Apex a commencé à décliner lorsque les applications ont dépassé la saisie de données CRUD et ont nécessité des comportements plus dynamiques et pilotés par les événements.
L'interface graphique basée sur le Web n'est pas cool. Le débogage est douloureux.
Contrôle de version? Qui a besoin d'un contrôle de version?
Lorsque vous (inévitablement) devez faire quoi que ce soit en dehors de la portée limitée du cadre, vous devrez vous salir les mains 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 était inconfortablement archaïque en 2007.
Étant donné le grand nombre d'endroits sournois où vous pouvez masquer 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. OOP les développeurs ne seront pas impressionnés. Il est possible d'avoir des applications maintenables bien structurées avec APEX mais c'est plus difficile qu'il ne devrait l'être. C'est loin de MVC.
Nombre inacceptable de bogues 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 de l'intégration de la IDE dans la plate-forme APEX elle-même m'a causé certains des plus sombres, détruisant l'âme débogage des sessions de ma vie . Par exemple, j'essayais de reproduire un bug intermittent qui ferait perdre un utilisateur de ses données de session. En utilisant le popup d'informations de session, j'ai vu que de temps en temps les données de session changerait alors qu'il n'aurait pas dû. J'ai passé 2 jours à essayer de trouver l'erreur dans mon code sans chance. 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'entrerait pas dans un état d'erreur. Mon cœur a coulé quand j'ai réalisé ce qui pouvait arriver. Oracle a confirmé plus tard que j'avais trouvé un bogue dans APEX qui faisait que la fenêtre d'informations sur la session me montrait par intermittence les données d'une session précédente. J'avais perdu 2 jours à déboguer un bug lié à la session avec une fenêtre de débogage de session buggy. Ce fut la dernière application Apex que j'ai construite.
PL/SQL n'est pas et ne sera jamais la Next Big Thing dans le développement web. Après avoir travaillé avec APEX pendant un certain temps, j'ai réalisé que ça n'allait pas me faire un meilleur développeur web. La maîtrise de l'APEX concerne vraiment PL/SQL. C'est très bien si vous prévoyez de concentrer votre carrière sur la technologie Oracle, sachez simplement que l'APEX est si tangentiel à la direction des technologies Web grand public que l'ensemble portable de compétences que vous pouvez transmettre d'APEX à d'autres cadres Web est minime.
Si vous envisagez que l'APEX fournisse une saisie de données et des rapports simples sur le Web, cela vaut le coup d'œil. Si vous cherchez une alternative à .NET/Java/PHP pour un contenu Web dynamique et une interaction d'interface utilisateur riche, je vous conseille de chercher ailleurs.
J'ai lu cette page avec grand intérêt. Notre équipe de développement utilise Apex depuis environ 2 ans maintenant, et je voudrais résumer notre expérience.
Pour créer des applications CRUD de base, Apex est vraiment excellent. En fait, je vous recommande de l'essayer vous-même. Nous avons rencontré des difficultés initiales mineures pour l'installer, mais celles-ci semblent avoir été résolues dans la version 3.2.
Le bon
- Idéal pour les applications simples. Si votre application grandit en complexité, envisagez une solution alternative.
- Les modèles intégrés signifient que votre application semble assez professionnelle (bien que certains en débattront).
- Un bon forum de soutien et une communauté, avec beaucoup de gens impatients à votre disposition pour vous aider.
- Quelques superbes commandes intégrées. J'adore les graphiques et les rapports (mais voir ci-dessous).
Le mauvais
Le débogueur est épouvantable. Si vous avez utilisé Visual Studio (et même des versions anciennes de Microsoft Access), vous grincerez des dents au débogueur. Pas de points d'arrêt, les messages de débogage crachent à l'écran dans une grande liste, devant imprimer manuellement les messages de débogage à l'écran. Horrible. La cause de nombreuses heures perdues à supporter.
Dès que votre application devient complexe ou nécessite des fonctionnalités riches, vous devez recourir à des hacks Javascript et HTML/CSS, ce qui rend le débogage et la prise en charge encore plus compliqués (bien que vous puissiez utiliser des outils comme Firebug ou Visual Studio pour vous y aider).
Nous avons rencontré des bogues d'état de session inexpliqués et des feuilles de style se "détachant" de l'application sans explication - pour ne nommer que quelques problèmes.
La prise en charge d'applications inconnues peut être difficile, car il peut être difficile de suivre le flux de la logique de page sans un bon débogueur. Et je n'achète pas la réponse boursière de "bien - les applications devraient être mieux codées". Parce que dans le monde réel, ils ne le sont pas - en particulier lorsque vous utilisez un entrepreneur.
Les rapports semblent bons mais pas très bons si vous ne pouvez pas les imprimer ou les exporter au format PDF. Bien sûr, vous pouvez utiliser Shell pour un serveur de rapports, à la fin, nous avons utilisé une autre solution.
Global
Je dirais certainement utiliser Apex pour de simples applications CRUD. Pour tout ce qui est plus que légèrement complexe, optez pour .Net ou Java. Je ne prendrais pas note de l'article Wiki sur Apex car il est très biaisé. Notez à quel point "difficile à déboguer" (à mon avis, le plus gros échec) a été effacé de l'article.
Il faut également se méfier de l'affirmation ridicule selon laquelle vous pouvez convertir rapidement des bases de données Access directement en Apex. Oui, cela fonctionnera si vous Access DB est très, très simpliste. Tout ce qui est moyennement complexe, oubliez-le, comme nous l'avons constaté.
Nous ne l'utiliserions certainement pas pour les applications Web, uniquement internes. Il y a tout simplement trop de difficultés à faire des choses que vous tiendriez pour acquises, par exemple .Net. Je sais qu'il existe des sites comme AskTom, mais ceux-ci ne sont pas exactement complexes. Verrons-nous le prochain Facebook dessus? Je ne pense pas - bien que je sois sûr que quelqu'un lisant ceci aura une fissure.
Apex est résumé dans un commentaire précédent - les gestionnaires voient les démos et adhèrent rapidement, convaincus qu'ils ont trouvé une solution miracle qui réduira les temps de développement. J'ai eu des gestionnaires qui m'appelaient et me disaient, nous avons besoin d'une application db avec 40 tables construites en une semaine dans Apex s'il vous plaît - c'est à quel point le mythe s'est perpétué. La réalité est quelque peu différente. Oui, certaines choses sont plus rapides, sensiblement plus rapides, mais vous perdrez du temps dans d'autres domaines - le débogage, le support et la personnalisation.
Bien sûr, il vaut mieux décider par vous-même. Installez-le, essayez-le, vous l'aimerez peut-être. Mais ne vous laissez pas berner par les délais de développement rapides tant que vous ne lui avez pas donné un bon aperçu d'une application réaliste.
Je suis impliqué dans un projet énorme pour migrer 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 l'APEX convient seulement pour les petites applications internes construites par les administrateurs de bases de données, les stagiaires ou les utilisateurs finaux: il convient certainement à celles-ci aussi (et plus approprié que la plupart des autres outils), mais il peut également être utilisé pour créer des applications extrêmement sophistiquées.
Pour créer une application sophistiquée (plutôt qu'une application APEX prête à l'emploi par défaut), vous aurez besoin de quelqu'un dans l'équipe avec des compétences Javascript et quelqu'un avec des compétences CSS. Mais la plupart des développeurs auront juste besoin de PL/SQL au départ.
Est-il évolutif? Oui: probablement plus évolutif que la plupart des autres solutions! APEX ajoute très peu de surcharge au serveur de base de données et seul le plus petit des serveurs d'applications est requis. "Taille Facebook"? Je ne sais pas avec certitude, mais je ne vois pas pourquoi, en supposant que vous ayez une base de données Oracle sur une machine suffisamment grande et puissante pour gérer les données et les volumes de transactions de "taille Facebook". Comme tout projet Oracle, l'évolutivité est entravée principalement par de mauvaises conceptions de base de données et un SQL mal écrit, et non par l'outil. Cependant, peu de gens se retrouvent à créer des systèmes de "taille Facebook": êtes-vous?
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 cadre inhibant, vous pouvez écrire des procédures PL/SQL et les exposer directement au serveur Web, mais toujours profiter de la sécurité, de la journalisation, de l'état de la session, etc. que le système APEX gère pour vous.
Vous devez connaître PL/SQL, SQL, HTML, JavaScript et CSS. Bien sûr, l'interface ressemble à une application de saisie de données volumineuses, mais les données que vous entrez seront principalement des extraits de code dans chacune de ces langues.
Il évolue aussi bien que la base de données. Il utilise généralement Apache comme serveur Web, mais n'est utilisé que pour servir des fichiers statiques et renvoyer les demandes à 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 monte et descend le long du canal. Vous pouvez définir la mise 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 à faire avec le cadre, il y aura naturellement des choses un peu plus compliquées à faire dans le cadre. L'exemple de codage couleur donné ci-dessus peut être quelque chose que vous faites avec CSS ou vous devrez peut-être vous tourner pour imprimer des instructions pour produire la sortie dont vous avez besoin. La chose est d'apprendre comment le cadre facilite la vie, puis lorsque vous atteignez une limite, vous pouvez facilement recourir à des méthodes plus directes.
En venant de VB.Net, vous manquerez le débogage étape par étape et le glisser-déposer. Vous ne manquerez jamais le fait qu'une partie du cycle de vie de la page effectuera une liaison et réinitialisera les valeurs que vous avez liées à un objet dans une autre partie de la page.
Bonne chance.
Greg
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) parce que mon travail est loin de développer des applications (sauf être pénible pour les développeurs) . Bien sûr, mon expérience est développeur et je crois que APEX est l'avenir des programmes centrés sur les données strictement basés sur Oracle.
Maintenant, le mot clé ici est centré sur les données, car je suis en désaccord avec de nombreux autres DBA sur le fait que toutes les applications sont centrées sur les données (vous savez le type de DBA qui pensent toujours ODBC signifie Oracle Bien sûr, toutes les applications impliquent des données, mais toutes les applications sont-elles centrées sur les données? Je doute, tout comme je doute qu'APEX soit jamais utilisé pour le traitement d'images ou les applications de jeux mobiles. Cependant, malgré tout le battage médiatique avec RIA et Web 2.0 le fait est que la plupart des entreprises autour de nous ont faim de ces vieilles applications centrées sur les données et Oracle est la meilleure base de données et je peux vous assurer qu'Oracle et APEX peuvent gérer beaucoup plus que l'évolutivité Facebook à condition bien sûr que vous ayez mis la même somme d'argent en tant que gars Facebook dans l'infrastructure sous-jacente.
Soit dit en passant, je déteste également la conception d'Oracle des thèmes APEX (interface utilisateur non professionnelle affreuse, imaginez-la simplement comme l'interface utilisateur principale pour une entreprise bancaire ou aérienne), des capacités limitées (bien que cela semble sur le point de changer à l'avenir), de nombreux autres problèmes (professionnels PDF rapports sans payer le montant de la licence Enterprise Database pour l'éditeur BI ??) mais surtout marketing d'APEX en remplacement d'Access ou Excel car cela donne une mauvaise impression que c'est pour les enfants et je peux vous assurer vous mon ami, je ne laisserais jamais les enfants toucher mes bases de données :)
Vous voyez, Oracle a un joyau appelé PL/SQL qui a été perfectionné au fil des ans pour gérer les données de manière beaucoup plus intuitive que tout autre langage. Maintenant que ce joyau se dessèche avec la mort lente des formulaires/rapports et je suis certain qu'aucun nouveau diplômé ne prendra la peine de l'apprendre strictement pour les procédures stockées dans la base de données (il suffit de voir la guerre qui fait rage entre Java et les développeurs .Net et vous vous rendez compte qu'une fois que vous touchez les accolades {}, tout le reste devient une hérésie. Hélas pour des milliers et des milliers d'excellents développeurs PL/SQL, APEX reste le seul sanctuaire 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 plate-forme de grade A beaucoup plus puissant que ce que nous voyons aujourd'hui. Soit cela, soit dites au revoir à PL/SQL et joignez les crochets avant ( d'ailleurs ce n'est jamais une mauvaise idée d'essayer au moins différentes technologies lorsque vous êtes développeur, au moins vous avez une idée pourquoi ce n'est pas nécessairement plus vert de l'autre côté).
Je ne sais pas pourquoi vous ne considérez pas PL/SQL comme un langage de programmation ...
APEX est idéal pour les applications internes où vous souhaitez une interface utilisateur légère au-dessus de vos données. Vous pouvez le construire assez facilement sans avoir à écrire de code.
Je trouve également que l'APEX est très bon pour développer des applications plus petites destinées aux clients. Je ne voudrais pas créer une application géante sur laquelle des centaines de développeurs travailleront avec APEX. Mais si vous avez un cas où 3 ou 4 développeurs construisent un petit site, APEX est susceptible d'être aussi bon que Java/PHP/ASP.Net/quoi que ce soit en supposant des développeurs également qualifiés. Si vos développeurs ont tous beaucoup d'expertise ASP.Net, par exemple, ils auront une courbe d'apprentissage pour écrire des applications APEX. Vous auriez au moins le même niveau de difficulté, cependant, si vous aviez un tas de développeurs PL/SQL, essayez d'apprendre à créer des sites ASP.Net.
Ne mettez pas de logique commerciale dans Apex. Utilisez-le uniquement pour la présentation.
Si vous mettez le code dans l'application, vous ne pourrez pas le maintenir et vous obtiendrez RSI de tout ce clic. Je crée toujours une couche wrapper, et dans le monde Oracle, suivez les conseils de Tom Kytes - placez la logique métier au plus près des données. Cela signifie également que vos modules PL/SQL peuvent être appelés par d'autres systèmes, etc. - et surtout - la vraie viande de votre application sera dans des fichiers texte simples qui peuvent être manipulés avec votre éditeur de texte/IDE préféré.
- Créez une vue avec toutes les données à récupérer pour chaque écran.
- Créez un package de wrapper unique pour toutes les opérations CRUD. (C'est créer, lire, mettre à jour et supprimer je présume)
En bref:
NE METTEZ PAS VOTRE LOGIQUE D'APPLICATION DANS APEX.
C'est mon conseil. . . .
Le site de support Metalink d'Oracle a été écrit en Apex, il peut donc certainement évoluer. Ils migrent maintenant vers un site de support Flash plus récent. Je comprends qu'ils ont acquis cette plate-forme par le biais d'une acquisition d'une autre société, plutôt que de la construire en réponse aux limites d'Apex.
Si vous voulez "super sexy" avec n'importe quelle application Web, vous devrez probablement utiliser Flash/Silverlight/Air. En vertu de cela, tout site HTML, y compris Apex, peut être doté de Javascript. La bibliothèque JQuery sera incluse dans la prochaine version principale d'Apex (4.0), bien que vous puissiez l'inclure (ou toute autre bibliothèque) maintenant.
Le problème de mise en cache mentionné dans l'article de Wikipédia a été résolu, bien que la plupart des installations placent toujours les images et les scripts sur une structure de répertoire conventionnelle plutôt que de les servir hors de la base de données.
Pendant que vous êtes enfermé dans la base de données Oracle, je ne reçois pas le verrou "plate-forme" "con" dans l'article. Oracle est disponible sur Windows, Linux et AIX (entre autres). C'est beaucoup moins de verrouillage que ASP/SQL Server.
Le fait qu'Apex ne convient qu'aux non-programmeurs et aux administrateurs de base de données est une fausse idée malheureuse. Nous l'avons utilisé pour créer plusieurs applications Web stratégiques, orientées client et orientées métier.
L'interface graphique est gérée par des modèles de page Apex (HTML), CSS et un peu de Javascript pour améliorer l'expérience utilisateur. Toute la logique métier est placée dans des packages PL/SQL. Ceci est essentiel pour faciliter la maintenance de votre application et pour réutiliser la logique métier dans d'autres applications Apex et à partir d'autres outils clients, tels que C # WinForms, Delphi, Java, etc.
Quant aux performances, le moteur Apex ajoute peu de temps et les temps de réponse et l'évolutivité de votre application dépendent largement de la qualité de vos requêtes SQL (et du modèle de données). Pensez-y de cette façon: avec Apex, la seule chose entre votre utilisateur et la base de données est une fine couche de PL/SQL. Il est logique que cela soit plus rapide qu'une application .NET classique ou Java application qui a dix-sept couches de complexité (comprenant généralement de nombreux services Web et couches de mappage relationnel objet) entre l'interface graphique) et la base de données.
Sur mon projet, nous utilisons Oracle APEX pour des vues internes de notre système. Cela fonctionne très bien à cet effet.
Aucune programmation n'est requise. PL/SQL et même SQL sont facultatifs. En conséquence, notre DBA et notre opérateur peuvent façonner la vue à leur guise.
En revanche, s'il y a une fonctionnalité dont vous avez besoin qui n'est pas programmée dans le système, il est très difficile de l'ajouter. Par exemple, nous voulions coder par couleur notre sortie et n'avons pas pu le faire.
Je ne voudrais pas avoir un site orienté client construit sur APEX.
Sur la question de l'évolutivité, une chose intéressante à propos d'APEX est qu'il est construit sur Oracle. Concentrez-vous sur l'écriture d'un bon SQL et la conception correcte des tables, et les choses devraient évoluer très bien. Je serais plus soucieux d'obtenir suffisamment d'utilisateurs pour que l'évolutivité soit le problème.
J'ai beaucoup aimé lire le fil de haut en bas, car cela ressemblait à un débat brûlant. Pour rappeler le début du fil de discussion, il a commencé par "Je crois que nous passons à Oracle Apex pour un développement futur ..." Jack étant un programmeur .NET était inquiet de la décision de sa direction et pensait trouver des contre-faits pour Oracle Apex qui a finalement fini par laver le linge sale (de tous les frameworks web) en public. Malgré le fait que la victime était Oracle Apex, la même chose pourrait arriver à .net ou j2ee si le débat était entre les gourous .net et j2ee. Mon point est que tous les cadres ont leurs propres avantages et inconvénients. C'est pourquoi nous en avons tellement. C'est une perte de temps de débattre de ce qui est le plus important à vivre (sexe, nourriture ou eau?). Naturellement, nous sélectionnons l'élément le plus approprié lorsque cela est nécessaire.
- Suites Oracle APEX pour les environnements où vous avez beaucoup de bases de données Oracle et où vous avez vraiment des passionnés de Pl/SQL. Peut vraiment créer des applications Web 2.0 riches et complexes Data Centric très facilement (Apex 4.0) mais le débogage et le contrôle de version sont toujours un gâchis et vous devrez également vous en tenir à une base de données Oracle (oui, vous pouvez avoir contournements mais pas robuste).
Si vous souhaitez voir un site Web externe réalisé dans APEX, je vous suggère de consulter le site Oracle Tools Users Group , ou Ask Tom . Les deux sont de grands sites fréquemment utilisés avec beaucoup de personnalisation.
Votre impression de l'article Wikipedia est correcte. La seule connaissance en programmation dont vous avez besoin est PL/SQL. Si la plupart de votre site sera constitué de rapports simples, vous n'avez même pas besoin d'écrire les requêtes SQL et l'interface de l'assistant créera la requête et la sortie pour vous. Si vous voulez travailler cool côté client, vous aurez besoin de connaître CSS et Javascript. Le PL/SQL est uniquement destiné à la validation de données plus complexe.
Je ne suis pas d'accord. Il ne convient pas uniquement aux développeurs ayant quelques compétences en développement ou DBA.
Nous produisons en fait des applications hautement personnalisées en utilisant nos propres modèles CSS, beaucoup d'actions dynamiques et d'interaction (en utilisant jQuery et plusieurs cadres), une sécurité affinée, nos propres plugins apex et des processus PL/SQL complexes.
Bien sûr, j'utilise apex> 4.0.
Ainsi, vous pouvez créer des applications complexes (nous avons jusqu'à 100 processus/validations différents et actions dynamiques par pages) si nécessaire. Et cela pourrait nécessiter de solides compétences en programmation pour coder correctement en javascript et PL/SQL (OOP) ou Java procédures stockées + une bonne connaissance de SQL pour définir des requêtes optimisées jusqu'à 500 lignes de code en utilisant SQL récursif et quelques fonctionnalités amusantes.