PL/SQL 不是也永远不会成为 Web 开发领域的下一个大事件。在使用 APEX 一段时间后，我意识到它不会让我成为更好的 Web 开发人员。 掌握 APEX 实际上与 PL/SQL 有关。 如果您打算将自己的职业重点放在 Oracle 技术上，那也没关系，只是要注意 APEX 与主流 Web 技术的方向非常不相干，以至于您可以从 APEX 到其他 Web 框架的可移植技能集很少。
如果您正在考虑 APEX 提供简单的基于 Web 的数据输入和报告，那么它值得一看。 如果您正在寻找 .NET/JAVA/PHP 的替代方案来实现动态 Web 内容和丰富的 UI 交互，我建议您去其他地方寻找。
Please note my experiences are with APEX 2.x-3.0.
I used Apex for a few internal apps over a 12 month period but eventually dumped it for ASP.NET.
Some Oracle evangelists claim it is capable of creating highly dynamic content on par with the more mainstream frameworks like ASP.NET/J2EE. Technically this is true, but then technically its also true that you could cross the atlantic in a one man canoe. If you are tempted to throw yourself into a APEX project of even moderate complexity then I suggest you look at the APEX sample of a simple discussion forum. Compare it to an ASP.NET MVC discussion forum sample or a RoR implementation.
Having said that:
The Good
Incredibly easy to generate a respectable web app with basic CRUD data entry, simple reporting and populate it with data. If you're the IT guy who's been tasked with consolidating a company's mess of Excel/Access dbs into a central DB/web environment then you should take a look at APEX, it very well suited for this task. If you expect the scope to grow to something of even moderate complexity then I would move straight to a more flexible framework.
If you are a DBA/PLSQL guru but have no experience with traditional web development you'll be well prepped to expose existing business logic in a web app without stuffing around with HTML/CSS/JavaScript if you dont want to.
APEX support forum has a ton of info and is well staffed by APEX devs.
The Bad
My experience with Apex began to go downhill when apps moved beyond CRUD data entry and required more dynamic and event driven behaviours.
The web based GUI is not cool. Debugging is painful.
Version Control? Who needs version control?
When you (inevitably) need to do anything outside the limited scope of the framework, you'll have to get your hands dirty with PL/SQL. Writing business logic against the database is fine, but generating HTML from PL/SQL procedures felt uncomfortably archaic in 2007.
Given the large number of sneaky places you can hide page and redirection logic, the program flow is both difficult to visualise and not naturally conducive to modular, separable and reusable code. OOP developers will be not be impressed. It's possible to have well structured maintainable applications with APEX but its harder than it should be. This is worlds away from MVC.
Unacceptable number of framework bugs in the versions I used. I'd hope this has improved with recent versions, but the paradigm of integrating the IDE into the APEX platform itself caused me some of the darkest, soul destroying debugging sessions of my life. As an example, I was trying to reproduce an intermittent bug that would cause a user to lose their session data. Using the session information popup I saw that occasionally the session data would change when it shouldnt have. I spent 2 days trying to find the error in my code with no luck. Near delirious, I noticed by pure chance that I could reproduce errorous session data in the debug window but the application itself wouldnt go into an error state. My heart sunk when I realised what might be happening. Oracle later confirmed that I'd found a bug in APEX that caused the session information window to intermittently show me data from a prior session. I'd wasted 2 days debugging a session related bug with a buggy session debug window. That was the last Apex app I built.
PL/SQL is not and will never be the Next Big Thing in web development. After working with APEX for a while I realised it wasnt going to make me a better web developer. Mastering APEX is really about PL/SQL. Thats fine if you plan to focus your career on Oracle technology, just be aware that APEX is so tangential to the direction of mainstream web technologies that the portable set of skills you can take from APEX to other web frameworks is minimal.
If you are considering APEX to provide simple web based data entry and reporting, its worth a look. If you are looking for an alternative to .NET/JAVA/PHP for dynamic web content and rich UI interaction I'd advise you to look elsewhere.
I read this page with great interest. Our development team has using Apex for about 2 years now, and I'd like to sum up our experience.
For building basic CRUD applications, Apex really is excellent. In fact I recommend you try it yourself. We did face some initial minor difficulties setting it up, but these seem to have been ironed out in the 3.2 release.
The good
Great for simple applications. If you app will grow in complexity, consider an alternative solution.
The built in templates mean your app looks quite professional (although some will debate this).
A good support forum and community, with plenty of eager people on hand to assist you.
Some superb built in controls. Love the graphs and reports (but see below).
The bad
The debugger is abysmal. If you have used Visual Studio (and even ancient versions of Microsoft Access), you will cringe at the debugger. No breakpoints, debug messages spewing out to screen in a big list, having to manually print debug messages to the screen. Horrible. The cause of many, many hours lost to support.
As soon as your application becomes complex or requires any rich functionality, you have to resort to Javascript and HTML / CSS hacks, which make debugging and support even more complicated (although you can use tools like Firebug or Visual Studio to assist with this).
We've encountered unexplained session state bugs, and stylesheets becoming 'detached' from the application without explanation - to name a couple of issues.
Supporting unfamiliar apps can be challenging, as it can be difficult to follow the page logic flow without a good debugger. And I don't buy the stock response of 'well - apps should be coded better'. Because in the real world, they aren't - especially when you're using a contractor.
Reports look good but not much good if you can't print them or export to PDF. Of course you can shell out for a reporting server, in the end we used another solution.
Overall
I would say by all means use Apex for simple CRUD apps. For anything of more than mild complexity go for .Net or Java. I wouldn't take any notice of the Wiki article on Apex as it's very skewed. Note how 'difficult to debug' (in my opinion the biggest failing) has been erased from the article.
Something to be very wary of as well is the ludicrous claim that you can quickly convert Access databases straight to Apex. Yes it will work if you Access DB is very, very simplistic. Anything moderately complex, forget it, as we found.
We would definitely not use it for web facing apps, only internal. There are simply too many difficulties doing things you would take for granted in say, .Net. I know there are sites out there such as AskTom, but these are not exactly complex. Will we see the next Facebook on it? I think not - although I am sure someone reading this will have a crack at it.
Apex is summed up in a previous comment - managers see the demos, and quickly buy in, convinced that they've found a silver bullet that will slash development times. I've had managers calling me and saying, we need a db app with 40 tables building in a week in Apex please - that's how far the myth has perpetrated. The reality is somewhat different. Yes some things are quicker, substantially quicker, but you will lose the time in other areas - debugging, support, and customisation.
Of course you are best deciding for yourself. Install it, give it a go, you may like it. But don't be fooled by the fast development time claims until you've given it a good going over on a realistic application.
I am involved in a huge project to migrate a 5000 module Oracle Forms application to APEX. This is an extreme use of APEX, but it's working just fine. It is a complete myth that APEX is suitable only for small internal apps built by DBAs, interns or end users: it is certainly suitable for those too (and more suitable than most other tools), but it can also be used to build extremely sophisticated applications.
To build a sophisticated application (rather than a default out-of-the box APEX one) you will need someone on the team with Javascript skills, and someone with CSS skills. But most developers will just need PL/SQL initially.
Is it scalable? Yes: probably more scalable than most other solutions! APEX adds very little overhead to the database server, and only the most minimal of application servers is required. "Facebook size"? I don't know for sure but I don't see why not, assuming you have an Oracle database on a machine large and powerful enough to handle "Facebook size" data and transaction volumes. Like any Oracle project, scalability is impeded mostly by bad database designs and poorly written SQL, not by the tool. Not many people ever find themselves building "Facebook size" systems though: are you?
APEX is a framework that uses the database and PL/SQL to produce web pages. If you can figure out what the output to the browser will need to be you can create it in APEX. If you find any part of the framework inhibiting you can write PL/SQL procedures and expose them to the web server directly but still take advantage of the security, logging, session state, etc that the APEX system manages for you.
You should know PL/SQL, SQL, HTML, JavaScript and CSS. Sure the interface looks like a big data entry application but the data you enter will mostly be code snippets in each of these languages.
It scales as well as the database does. It typically uses Apache as a web server but is only used to serve static files and pass requests back to the database, where the web pages are created by the PL/SQL code in the APEX schema. You can use AJAX to minimize the size of the traffic traveling up and down the pipe. You can set caching for specific items, lists, page regions, pages, etc.
Since most things are pretty simple to do with the framework, naturally there will be some things that are a little more complicated to do within the framework. The color coding example given above might be something you do with CSS or maybe you would need to turn to print statements to produce the output you need. The thing is to learn the how the framework makes life easier and then when you hit a limit you can easily resort to more direct methods.
Coming from VB.Net you will miss the step by step debugging and the drag and drop. You will never miss the fact that some part of the page lifecycle will do a bind and reset the values you bound to an object in another part of the page.
I am a DBA and I never had to program with APEX or recently anything else (aside some bash scripting and custom SQL scripts for administration purposes) because my job is far away from developing applications (except being pain in the ass of developers that is). Of course my background is developer though and I do believe APEX is future for strictly Oracle based data centric programs.
Now the keyword here is data centric since I disagree with many other DBAs that all applications are data centric (you know the kind of DBAs who still think ODBC stands for ORACLE Database Connectivity). Of course all applications involve data but are all applications data centric? I doubt, just as I doubt APEX would be ever used for image processing or mobile gaming kind of apps. However, despite all the hype with RIA and Web 2.0 the fact is most of businesses around us are hungry for those plain old data centric applications and Oracle is best database around and I can assure you Oracle and APEX can handle much much more than Facebook scalability provided of course you have put the same amount of money as Facebook guys in underlying infrastructure.
By the way I also hate Oracle's design of APEX themes (awful unprofessional UI, just imagine it as main UI for a bank or airline business), limited capabilities (although that seems about to change in the future), many many more issues (professional PDF reporting without paying amount of Enterprise Database license for BI publisher??) but most of all marketing of APEX as substitute of Access or Excel because it gives bad impression it is for kids and I can assure you my friend I would never allow kids to touch my databases :)
You see, Oracle has a gem called PL/SQL which was perfected over the years to handle data in much more intutitive way than any other language. Now that gem is withering with slow death of Forms/Reports and I am positive no fresh graduate will ever bother learning it strictly for database stored procedures (just see the raging war between Java and .Net developers and you realize that once you touch curly brackets {} anything else becomes a heresy). Alas for thousands upon thousands of excellent PL/SQL developers APEX remains the only sanctuary where they can remain productive and develop outstanding data centric applications and without APEX PL/SQL will surely become next COBOL. This is why PL/SQL community will drive Oracle to transform APEX to grade A platform much more powerful than what we are seeing today. Either that or say bye bye to PL/SQL and join curly brackets front (by the way it is never a bad idea to at least try different technologies when you are developer, at least you get an idea why it is not neccessarily greener at the other side).
I'm not sure why you don't consider PL/SQL a programming language...
APEX is ideal for internal applications where you want a lightweight UI on top of your data. You can build that rather easily without having to write any code.
I also find APEX to be very good for developing smaller customer-facing applications. I wouldn't want to build a giant application that is going to have hundreds of developers working on it using APEX. But if you have a case where 3 or 4 developers are building a smallish site, APEX is likely to be just as good as Java/PHP/ASP.Net/whatever assuming equally skilled developers. If your developers all have lots of ASP.Net expertise, for example, they're going to have a learning curve to write APEX apps. You'd have at least the same level of difficulty, though, if you had a bunch of PL/SQL developers try to learn how to build ASP.Net sites.
That Apex is only suitable for non-programmers and DBAs is an unfortunate misconception. We have used it to build several line-of-business, mission-critical, customer-facing web applications.
The GUI is handled by Apex page templates (HTML), CSS and a bit of Javascript to enhance the user experience. All business logic is placed in PL/SQL packages. This is key to making your application easy to maintain, and to reuse the business logic in other Apex applications and from other client tools, such as C# WinForms, Delphi, Java apps, etc.
As for performance, the Apex engine adds little overhead and the response times and scalability of your application depends largely on the quality of your SQL queries (and the data model). Think about it this way: With Apex, the only thing between your user and the database is a thin layer of PL/SQL. It's only common sense that this has to be faster than a typical .NET or Java application that has seventeen layers of complexity (typically including lots of web services and object-relational mapping layers) between the GUI and the database.
Don't put buisiness logic into Apex. Use it for presentation only.
If you put the code in the app your will not be able to maintain it, and you'll get RSI from all that clicking. I always create a wrapper layer, and in the oracle world follow Tom Kytes advise - put the business logic as close to the data as possible. This also means that you PL/SQL modules can be called by other systems etc - and best of all - the real meat of your applicaiton will be in straight text files that can be manipulated with your favourite text editor / IDE.
Create a view with all of the data to be retrieved for each screen.
Create a single wrapper package for all CRUD operations. (Thats is Create, Read, Update and Delete I presume)
当您被锁定到 Oracle 数据库时，我没有得到本文中的“平台”锁定“con”。 Oracle 可在 Windows、Linux 和 AIX（等等）上使用。 这比 ASP / SQL Server 少了很多锁。
Oracle's Metalink support site was written in Apex, so it definitely CAN scale. They're migrating to a newer Flash-based support site now though. I understand they acquired that platform through an aquisition of another company, rather than building it in response to any Apex limits.
If you want 'super sexy' with any web-app, you'd probably need to go Flash/Silverlight/Air. Under that, any HTML based site, including an Apex one, can be prettied up with Javascript. The JQuery library will be included in with the next main version of Apex (4.0), though you can include that (or any other library) now.
The caching issue mentioned in the Wikipedia article has been addressed, though most installations would still put images and scripts on a conventional directory structure rather than serving them out of the database.
While you are locked into the Oracle database, I don't get the 'platform' lock "con" in the article. Oracle is available on Windows, Linux and AIX (amongst others). That's a lot less lock than ASP / SQL Server.
On my project, we use Oracle APEX for internal views of our system. It works very well for that purpose.
There's no programming required. PL/SQL and even SQL are optional. As a result, our DBA and operator can mold the view to their liking.
On the downside, if there's a feature you need which is not programmed into the system, it's very hard to add it. For instance, we wanted to color-code our output and have not been able to do that.
I would not want to have a customer-facing site built on APEX.
On the question of scalability, one nice thing about APEX is that it's built on Oracle. Focus on writing good SQL and designing the tables properly, and things should scale just fine. I'd be more concerned about getting enough users for scalability to be the problem.
Enjoyed very much reading the thread from top to bottom, as it felt like a hot debate. To remind the start of the thread it started as "I believe we're moving to Oracle Apex for future development..." jack being a .NET programmer was worried about the decision of his management and thought of finding counter facts for Oracle Apex which ultimately ended up washing the dirty linen (of all web frameworks) in public. Despite the fact that the victim was Oracle Apex, the same could happen to either .net or j2ee if the debate was between .net and j2ee gurus. My point is all frameworks has their own pros and cons. That is why actually we have so many. Its a waste of time debating over what is more important to live (sex, food or water?) Naturally we select the most appropriate item when that is needed.
Oracle APEX suites for environments where you have lots of Oracle Databases and when you really have Pl/SQL enthusiasts. Can really build rich, complex, web 2.0 Data Centric applications really easily (Apex 4.0) but debugging and version control is still a mess and you also will have to stick to an Oracle database(yes you can have workarounds but not robust).
If you'd like to see an external web site done in APEX, I suggest looking at the Oracle Tools Users Group site, or Ask Tom. Both are large, frequently used sites with much customization.
Your impression from the Wikipedia article is correct. The only programming knowledge you need is PL/SQL. If most of your site will be simple reports, you don't even need to write the SQL queries, and the wizard interface will build the query and the output for you. If you want cool client side work, you will need to know CSS and Javascript. The PL/SQL is only for the more complex data validation.
I disagree. It is not only suitable to devs with a few developing skills or DBAs.
We actually produce highly customized apps using CSS templates of our own, a lot of dynamic actions and interaction (using jQuery and several frameworks), fine-tuned security, our own apex plugins and complex PL/SQL processes.
Of course, I am using apex > 4.0.
So, you can build complex apps (we have up to 100 different processes/validations and dynamic actions per pages) if needed. And it could require strong programming skills to code properly in javascript and PL/SQL(OOP) or Java stored procedures + a good knowledge of SQL to define opimized queries of up to 500 lines of code using recursive SQL and some funny features.
发布评论
评论（13）
请注意我的经验是 APEX 2.x-3.0。
在 12 个月的时间里，我将 Apex 用于一些内部应用程序，但最终放弃了它并转而使用 ASP.NET。
一些 Oracle 传播者声称它能够创建与 ASP.NET/J2EE 等更主流的框架相媲美的高度动态的内容。 从技术上讲这是事实，但从技术上讲，你可以乘坐独木舟横渡大西洋也是事实。 如果您想投入到中等复杂度的 APEX 项目中，那么我建议您查看 简单的讨论论坛。 将其与 ASP.NET MVC 讨论论坛示例或 RoR 实现进行比较。
话虽如此：
好处
非常容易生成一个受人尊敬的网络应用程序，具有基本的 CRUD 数据输入、简单的报告并用数据填充它。 如果您是 IT 人员，负责将公司混乱的 Excel/Access 数据库整合到中央数据库/Web 环境中，那么您应该看看 APEX，它非常适合这项任务。 如果您预计范围会增长到中等复杂度，那么我会直接转向更灵活的框架。
如果您是 DBA/PLSQL 专家，但没有传统 Web 开发经验，那么您将做好充分准备，在 Web 应用程序中公开现有业务逻辑，而无需使用 HTML/CSS/JavaScript（如果您不愿意）。
APEX 支持论坛包含大量信息，并且配备了充足的 APEX 开发人员。
坏处
当应用程序超越 CRUD 数据输入并需要更多动态和事件驱动的行为时，我对 Apex 的体验开始走下坡路。
基于 Web 的 GUI 并不酷。 调试是痛苦的。
版本控制？ 谁需要版本控制？
当您（不可避免地）需要在框架的有限范围之外做任何事情时，您将不得不亲自动手使用 PL/SQL。 针对数据库编写业务逻辑很好，但是在 2007 年，从 PL/SQL 过程生成 HTML 感觉有点过时了。
鉴于有大量可以隐藏页面和重定向逻辑的隐蔽位置，程序流程既难以可视化，又难以实现。自然不利于模块化、可分离和可重用的代码。 OOP 开发人员不会对此印象深刻。 使用 APEX 可以拥有结构良好、可维护的应用程序，但它比应有的更难。 这与 MVC 相差甚远。
我使用的版本中存在数量不可接受的框架错误。 我希望这一点在最近的版本中有所改善，但是将 IDE 集成到 APEX 平台本身的范例给我带来了一些我一生中最黑暗、毁灭灵魂的调试会话。 举个例子，我试图重现一个间歇性错误，该错误会导致用户丢失会话数据。 使用会话信息弹出窗口，我发现会话数据有时会在不应该发生的情况下发生变化。 我花了两天时间试图找出代码中的错误，但没有成功。 近乎疯狂的是，我偶然注意到我可以在调试窗口中重现错误的会话数据，但应用程序本身不会进入错误状态。 当我意识到可能会发生什么时，我的心沉了下去。 Oracle 后来确认我在 APEX 中发现了一个错误，该错误导致会话信息窗口间歇性地向我显示先前会话的数据。 我浪费了 2 天的时间使用有问题的会话调试窗口来调试与会话相关的错误。 那是我构建的最后一个 Apex 应用程序。
PL/SQL 不是也永远不会成为 Web 开发领域的下一个大事件。在使用 APEX 一段时间后，我意识到它不会让我成为更好的 Web 开发人员。 掌握 APEX 实际上与 PL/SQL 有关。 如果您打算将自己的职业重点放在 Oracle 技术上，那也没关系，只是要注意 APEX 与主流 Web 技术的方向非常不相干，以至于您可以从 APEX 到其他 Web 框架的可移植技能集很少。
如果您正在考虑 APEX 提供简单的基于 Web 的数据输入和报告，那么它值得一看。 如果您正在寻找 .NET/JAVA/PHP 的替代方案来实现动态 Web 内容和丰富的 UI 交互，我建议您去其他地方寻找。
Please note my experiences are with APEX 2.x-3.0.
I used Apex for a few internal apps over a 12 month period but eventually dumped it for ASP.NET.
Some Oracle evangelists claim it is capable of creating highly dynamic content on par with the more mainstream frameworks like ASP.NET/J2EE. Technically this is true, but then technically its also true that you could cross the atlantic in a one man canoe. If you are tempted to throw yourself into a APEX project of even moderate complexity then I suggest you look at the APEX sample of a simple discussion forum. Compare it to an ASP.NET MVC discussion forum sample or a RoR implementation.
Having said that:
The Good
Incredibly easy to generate a respectable web app with basic CRUD data entry, simple reporting and populate it with data. If you're the IT guy who's been tasked with consolidating a company's mess of Excel/Access dbs into a central DB/web environment then you should take a look at APEX, it very well suited for this task. If you expect the scope to grow to something of even moderate complexity then I would move straight to a more flexible framework.
If you are a DBA/PLSQL guru but have no experience with traditional web development you'll be well prepped to expose existing business logic in a web app without stuffing around with HTML/CSS/JavaScript if you dont want to.
APEX support forum has a ton of info and is well staffed by APEX devs.
The Bad
My experience with Apex began to go downhill when apps moved beyond CRUD data entry and required more dynamic and event driven behaviours.
The web based GUI is not cool. Debugging is painful.
Version Control? Who needs version control?
When you (inevitably) need to do anything outside the limited scope of the framework, you'll have to get your hands dirty with PL/SQL. Writing business logic against the database is fine, but generating HTML from PL/SQL procedures felt uncomfortably archaic in 2007.
Given the large number of sneaky places you can hide page and redirection logic, the program flow is both difficult to visualise and not naturally conducive to modular, separable and reusable code. OOP developers will be not be impressed. It's possible to have well structured maintainable applications with APEX but its harder than it should be. This is worlds away from MVC.
Unacceptable number of framework bugs in the versions I used. I'd hope this has improved with recent versions, but the paradigm of integrating the IDE into the APEX platform itself caused me some of the darkest, soul destroying debugging sessions of my life. As an example, I was trying to reproduce an intermittent bug that would cause a user to lose their session data. Using the session information popup I saw that occasionally the session data would change when it shouldnt have. I spent 2 days trying to find the error in my code with no luck. Near delirious, I noticed by pure chance that I could reproduce errorous session data in the debug window but the application itself wouldnt go into an error state. My heart sunk when I realised what might be happening. Oracle later confirmed that I'd found a bug in APEX that caused the session information window to intermittently show me data from a prior session. I'd wasted 2 days debugging a session related bug with a buggy session debug window. That was the last Apex app I built.
PL/SQL is not and will never be the Next Big Thing in web development. After working with APEX for a while I realised it wasnt going to make me a better web developer. Mastering APEX is really about PL/SQL. Thats fine if you plan to focus your career on Oracle technology, just be aware that APEX is so tangential to the direction of mainstream web technologies that the portable set of skills you can take from APEX to other web frameworks is minimal.
If you are considering APEX to provide simple web based data entry and reporting, its worth a look. If you are looking for an alternative to .NET/JAVA/PHP for dynamic web content and rich UI interaction I'd advise you to look elsewhere.
我饶有兴趣地阅读了这一页。 我们的开发团队使用Apex已经有两年了，我想总结一下我们的经验。
对于构建基本的 CRUD 应用程序，Apex 确实非常出色。 事实上我建议你自己尝试一下。 我们在设置时确实遇到了一些最初的小困难，但这些问题似乎已在 3.2 版本中得到解决。
优点
坏处
调试器很糟糕。 如果您使用过 Visual Studio（甚至是 Microsoft Access 的旧版本），您会对调试器感到畏缩。 没有断点，调试消息以大列表的形式喷涌到屏幕上，必须手动将调试消息打印到屏幕上。 可怕。 造成很多很多小时失去支持。
一旦您的应用程序变得复杂或需要任何丰富的功能，您就必须求助于 Javascript 和 HTML / CSS hack，这使得调试和支持变得更加复杂（尽管您可以使用 Firebug 或 Visual Studio 等工具来协助 ）
我们遇到了无法解释的会话状态错误，并且样式表在没有解释的情况下与应用程序“分离” - 仅举几个问题。
支持不熟悉的应用程序可能具有挑战性，因为如果没有良好的调试器，就很难遵循页面逻辑流程。 我不相信“好吧——应用程序应该编码得更好”的普遍反应。 因为在现实世界中，它们并非如此，尤其是当您使用承包商时。
报告看起来不错，但如果无法打印或导出为 PDF，则效果不佳。 当然，您可以花钱购买报告服务器，最后我们使用了另一种解决方案。
总体
我想说，对于简单的 CRUD 应用程序，请务必使用 Apex。 对于超过中等复杂性的任何事情，请选择.Net 或Java。 我不会注意到 Apex 上的 Wiki 文章，因为它非常扭曲。 请注意“难以调试”（在我看来是最大的失败）是如何从文章中删除的。
还需要非常警惕的是可笑的说法，即您可以将 Access 数据库直接快速转换为 Apex。 是的，如果您的访问数据库非常非常简单，它就会起作用。 正如我们发现的那样，任何中等复杂的事情都可以忘记。
我们绝对不会将它用于面向网络的应用程序，而仅用于内部应用程序。 在 .Net 中，做一些你认为理所当然的事情有太多的困难。 我知道有一些网站，例如 AskTom，但这些网站并不复杂。 我们会看到下一个 Facebook 吗？ 我认为不会——尽管我确信读过这篇文章的人会理解它。
Apex 在之前的评论中得到了总结 - 经理们看到了演示，并迅速接受，确信他们已经找到了可以缩短开发时间的灵丹妙药。 我曾有经理打电话给我说，我们需要一个数据库应用程序，在 Apex 中一周内构建 40 个表 - 这就是神话已经流传到的程度。 现实有些不同。 是的，有些事情会更快，明显更快，但您会在其他方面浪费时间 - 调试、支持和定制。
当然，你最好自己决定。 安装它，尝试一下，你可能会喜欢它。 但是，在您在实际应用程序中对其进行了良好的检查之前，请不要被快速开发时间的说法所迷惑。
I read this page with great interest. Our development team has using Apex for about 2 years now, and I'd like to sum up our experience.
For building basic CRUD applications, Apex really is excellent. In fact I recommend you try it yourself. We did face some initial minor difficulties setting it up, but these seem to have been ironed out in the 3.2 release.
The good
The bad
The debugger is abysmal. If you have used Visual Studio (and even ancient versions of Microsoft Access), you will cringe at the debugger. No breakpoints, debug messages spewing out to screen in a big list, having to manually print debug messages to the screen. Horrible. The cause of many, many hours lost to support.
As soon as your application becomes complex or requires any rich functionality, you have to resort to Javascript and HTML / CSS hacks, which make debugging and support even more complicated (although you can use tools like Firebug or Visual Studio to assist with this).
We've encountered unexplained session state bugs, and stylesheets becoming 'detached' from the application without explanation - to name a couple of issues.
Supporting unfamiliar apps can be challenging, as it can be difficult to follow the page logic flow without a good debugger. And I don't buy the stock response of 'well - apps should be coded better'. Because in the real world, they aren't - especially when you're using a contractor.
Reports look good but not much good if you can't print them or export to PDF. Of course you can shell out for a reporting server, in the end we used another solution.
Overall
I would say by all means use Apex for simple CRUD apps. For anything of more than mild complexity go for .Net or Java. I wouldn't take any notice of the Wiki article on Apex as it's very skewed. Note how 'difficult to debug' (in my opinion the biggest failing) has been erased from the article.
Something to be very wary of as well is the ludicrous claim that you can quickly convert Access databases straight to Apex. Yes it will work if you Access DB is very, very simplistic. Anything moderately complex, forget it, as we found.
We would definitely not use it for web facing apps, only internal. There are simply too many difficulties doing things you would take for granted in say, .Net. I know there are sites out there such as AskTom, but these are not exactly complex. Will we see the next Facebook on it? I think not - although I am sure someone reading this will have a crack at it.
Apex is summed up in a previous comment - managers see the demos, and quickly buy in, convinced that they've found a silver bullet that will slash development times. I've had managers calling me and saying, we need a db app with 40 tables building in a week in Apex please - that's how far the myth has perpetrated. The reality is somewhat different. Yes some things are quicker, substantially quicker, but you will lose the time in other areas - debugging, support, and customisation.
Of course you are best deciding for yourself. Install it, give it a go, you may like it. But don't be fooled by the fast development time claims until you've given it a good going over on a realistic application.
我参与了一个大型项目，将 5000 个模块的 Oracle Forms 应用程序迁移到 APEX。 这是 APEX 的极端使用，但它工作得很好。 APEX 仅适合 DBA、实习生或最终用户构建的小型内部应用程序，这完全是一个神话：它当然也适合这些人（并且比大多数其他工具更适合），但它可以也可用于构建极其复杂的应用程序。
要构建一个复杂的应用程序（而不是默认的开箱即用的 APEX 应用程序），您需要团队中有人具备 Javascript 技能，也需要有人具备 CSS 技能。 但大多数开发人员最初只需要 PL/SQL。
它具有可扩展性吗？ 是的：可能比大多数其他解决方案更具可扩展性！ APEX 给数据库服务器增加的开销非常小，并且只需要最少的应用程序服务器。 “脸书尺寸”？ 我不确定，但我不明白为什么不这样做，假设您在一台足够大且功能强大的机器上有一个 Oracle 数据库，可以处理“Facebook 大小”的数据和交易量。 与任何 Oracle 项目一样，可扩展性的阻碍主要是由于糟糕的数据库设计和糟糕的 SQL 编写，而不是工具。 不过，没有多少人发现自己正在构建“Facebook 大小”的系统：你是吗？
I am involved in a huge project to migrate a 5000 module Oracle Forms application to APEX. This is an extreme use of APEX, but it's working just fine. It is a complete myth that APEX is suitable only for small internal apps built by DBAs, interns or end users: it is certainly suitable for those too (and more suitable than most other tools), but it can also be used to build extremely sophisticated applications.
To build a sophisticated application (rather than a default out-of-the box APEX one) you will need someone on the team with Javascript skills, and someone with CSS skills. But most developers will just need PL/SQL initially.
Is it scalable? Yes: probably more scalable than most other solutions! APEX adds very little overhead to the database server, and only the most minimal of application servers is required. "Facebook size"? I don't know for sure but I don't see why not, assuming you have an Oracle database on a machine large and powerful enough to handle "Facebook size" data and transaction volumes. Like any Oracle project, scalability is impeded mostly by bad database designs and poorly written SQL, not by the tool. Not many people ever find themselves building "Facebook size" systems though: are you?
APEX是一个使用数据库和PL/SQL来生成网页的框架。 如果您能弄清楚浏览器的输出需要什么，您可以在 APEX 中创建它。 如果您发现框架的任何部分受到限制，您可以编写 PL/SQL 过程并将它们直接暴露给 Web 服务器，但仍然可以利用 APEX 系统为您管理的安全性、日志记录、会话状态等。
您应该了解 PL/SQL、SQL、HTML、JavaScript 和 CSS。 当然，界面看起来像一个大数据输入应用程序，但您输入的数据主要是每种语言的代码片段。
它的扩展能力与数据库一样好。 它通常使用 Apache 作为 Web 服务器，但仅用于提供静态文件并将请求传递回数据库，其中网页由 APEX 模式中的 PL/SQL 代码创建。 您可以使用 AJAX 来最大程度地减少管道上下行的流量大小。 您可以为特定项目、列表、页面区域、页面等设置缓存。
由于使用框架完成大多数事情都非常简单，因此自然会有一些事情在框架内完成起来会稍微复杂一些。 上面给出的颜色编码示例可能是您使用 CSS 执行的操作，或者您可能需要转向 print 语句来生成您需要的输出。 重要的是要了解框架如何让生活变得更轻松，然后当您达到极限时，您可以轻松地诉诸更直接的方法。
从 VB.Net 开始，您将错过逐步调试和拖放操作。 您永远不会错过这样一个事实：页面生命周期的某些部分将进行绑定并重置您绑定到页面另一部分中的对象的值。
祝你好运。
格雷格
APEX is a framework that uses the database and PL/SQL to produce web pages. If you can figure out what the output to the browser will need to be you can create it in APEX. If you find any part of the framework inhibiting you can write PL/SQL procedures and expose them to the web server directly but still take advantage of the security, logging, session state, etc that the APEX system manages for you.
You should know PL/SQL, SQL, HTML, JavaScript and CSS. Sure the interface looks like a big data entry application but the data you enter will mostly be code snippets in each of these languages.
It scales as well as the database does. It typically uses Apache as a web server but is only used to serve static files and pass requests back to the database, where the web pages are created by the PL/SQL code in the APEX schema. You can use AJAX to minimize the size of the traffic traveling up and down the pipe. You can set caching for specific items, lists, page regions, pages, etc.
Since most things are pretty simple to do with the framework, naturally there will be some things that are a little more complicated to do within the framework. The color coding example given above might be something you do with CSS or maybe you would need to turn to print statements to produce the output you need. The thing is to learn the how the framework makes life easier and then when you hit a limit you can easily resort to more direct methods.
Coming from VB.Net you will miss the step by step debugging and the drag and drop. You will never miss the fact that some part of the page lifecycle will do a bind and reset the values you bound to an object in another part of the page.
Good luck.
Greg
我是一名 DBA，我从来不需要使用 APEX 或最近的任何其他东西进行编程（除了一些出于管理目的的 bash 脚本和自定义 SQL 脚本），因为我的工作远离开发应用程序（除了让开发人员感到痛苦之外） 。 当然，我的背景是开发人员，而且我确实相信 APEX 是严格基于 Oracle 的以数据为中心的程序的未来。
现在，这里的关键词是以数据为中心，因为我不同意许多其他 DBA 的观点，即所有应用程序都是以数据为中心的（您知道哪些 DBA 仍然认为 ODBC 代表 ORACLE 数据库连接）。 当然，所有应用程序都涉及数据，但是所有应用程序都以数据为中心吗？ 我怀疑，就像我怀疑 APEX 是否会用于图像处理或移动游戏类型的应用程序一样。 然而，尽管对 RIA 和 Web 2.0 进行了大肆宣传，但事实是我们周围的大多数企业都渴望那些以数据为中心的普通旧应用程序，而 Oracle 是最好的数据库，我可以向您保证 Oracle 和 APEX 可以处理比 Facebook 更强大的可扩展性当然，前提是你在底层基础设施上投入了与 Facebook 相同数量的资金。
顺便说一句，我也讨厌 Oracle 的 APEX 主题设计（可怕的不专业的 UI，想象一下它是银行或航空公司的主 UI），有限的功能（尽管这似乎在未来会改变），还有更多的问题（专业PDF 报告无需为 BI 发布者支付企业数据库许可证？），但最重要的是 APEX 的营销作为 Access 或 Excel 的替代品，因为它给孩子们留下了不好的印象，我可以向你保证，我的朋友，我永远不会允许孩子们触摸我的数据库 :)
你看，Oracle 有一个名为 PL/SQL 的宝石，多年来它已经得到完善，能够以比任何其他语言更直观的方式处理数据。 现在，随着 Forms/Reports 的缓慢消亡，gem 正在枯萎，我确信没有哪个应届毕业生会费心去严格学习数据库存储过程（只要看看 Java 和 .Net 开发人员之间的激烈战争，你就会意识到，一旦你接触到大括号） {}其他任何事情都会成为异端）。 对于成千上万优秀的 PL/SQL 开发人员来说，遗憾的是 APEX 仍然是他们保持生产力并开发出色的以数据为中心的应用程序的唯一庇护所，没有 APEX PL/SQL 肯定会成为下一个 COBOL。 这就是为什么 PL/SQL 社区将推动 Oracle 将 APEX 转变为比我们今天看到的更强大的 A 级平台。 要么这样，要么告别 PL/SQL 并在前面加入大括号（顺便说一句，当你是开发人员时，至少尝试不同的技术从来不是一个坏主意，至少你知道为什么它不一定更环保）对方）。
I am a DBA and I never had to program with APEX or recently anything else (aside some bash scripting and custom SQL scripts for administration purposes) because my job is far away from developing applications (except being pain in the ass of developers that is). Of course my background is developer though and I do believe APEX is future for strictly Oracle based data centric programs.
Now the keyword here is data centric since I disagree with many other DBAs that all applications are data centric (you know the kind of DBAs who still think ODBC stands for ORACLE Database Connectivity). Of course all applications involve data but are all applications data centric? I doubt, just as I doubt APEX would be ever used for image processing or mobile gaming kind of apps. However, despite all the hype with RIA and Web 2.0 the fact is most of businesses around us are hungry for those plain old data centric applications and Oracle is best database around and I can assure you Oracle and APEX can handle much much more than Facebook scalability provided of course you have put the same amount of money as Facebook guys in underlying infrastructure.
By the way I also hate Oracle's design of APEX themes (awful unprofessional UI, just imagine it as main UI for a bank or airline business), limited capabilities (although that seems about to change in the future), many many more issues (professional PDF reporting without paying amount of Enterprise Database license for BI publisher??) but most of all marketing of APEX as substitute of Access or Excel because it gives bad impression it is for kids and I can assure you my friend I would never allow kids to touch my databases :)
You see, Oracle has a gem called PL/SQL which was perfected over the years to handle data in much more intutitive way than any other language. Now that gem is withering with slow death of Forms/Reports and I am positive no fresh graduate will ever bother learning it strictly for database stored procedures (just see the raging war between Java and .Net developers and you realize that once you touch curly brackets {} anything else becomes a heresy). Alas for thousands upon thousands of excellent PL/SQL developers APEX remains the only sanctuary where they can remain productive and develop outstanding data centric applications and without APEX PL/SQL will surely become next COBOL. This is why PL/SQL community will drive Oracle to transform APEX to grade A platform much more powerful than what we are seeing today. Either that or say bye bye to PL/SQL and join curly brackets front (by the way it is never a bad idea to at least try different technologies when you are developer, at least you get an idea why it is not neccessarily greener at the other side).
我不知道为什么您不认为 PL/SQL 是一种编程语言...
APEX 非常适合您希望在数据之上提供轻量级 UI 的内部应用程序。 您可以相当轻松地构建它，而无需编写任何代码。
我还发现 APEX 非常适合开发面向客户的小型应用程序。 我不想构建一个庞大的应用程序，让数百名开发人员使用 APEX 进行开发。 但是，如果您有 3 或 4 名开发人员正在构建一个小型站点，则 APEX 可能与 Java/PHP/ASP.Net/任何其他技术相同的开发人员一样好。 例如，如果您的开发人员都拥有大量 ASP.Net 专业知识，那么他们将有一个学习曲线来编写 APEX 应用程序。 但是，如果您有一群 PL/SQL 开发人员尝试学习如何构建 ASP.Net 站点，那么您至少会遇到同样的难度。
I'm not sure why you don't consider PL/SQL a programming language...
APEX is ideal for internal applications where you want a lightweight UI on top of your data. You can build that rather easily without having to write any code.
I also find APEX to be very good for developing smaller customer-facing applications. I wouldn't want to build a giant application that is going to have hundreds of developers working on it using APEX. But if you have a case where 3 or 4 developers are building a smallish site, APEX is likely to be just as good as Java/PHP/ASP.Net/whatever assuming equally skilled developers. If your developers all have lots of ASP.Net expertise, for example, they're going to have a learning curve to write APEX apps. You'd have at least the same level of difficulty, though, if you had a bunch of PL/SQL developers try to learn how to build ASP.Net sites.
Apex 仅适合非程序员和 DBA 是一个不幸的误解。 我们已经使用它构建了多个业务线、任务关键型、面向客户的 Web 应用程序。
GUI 由 Apex 页面模板 (HTML)、CSS 和一些 Javascript 处理，以增强用户体验。 所有业务逻辑都放置在 PL/SQL 包中。 这是使您的应用程序易于维护以及在其他 Apex 应用程序和其他客户端工具（例如 C# WinForms、Delphi、Java 应用程序等）中重用业务逻辑的关键。
至于性能，Apex 引擎增加的开销很少，并且应用程序的响应时间和可扩展性很大程度上取决于 SQL 查询（和数据模型）的质量。 可以这样想：使用 Apex，用户和数据库之间的唯一东西就是一层薄薄的 PL/SQL。 这是常识，这必须比 GUI 和数据库之间具有十七层复杂性（通常包括大量 Web 服务和对象关系映射层）的典型 .NET 或 Java 应用程序更快。
That Apex is only suitable for non-programmers and DBAs is an unfortunate misconception. We have used it to build several line-of-business, mission-critical, customer-facing web applications.
The GUI is handled by Apex page templates (HTML), CSS and a bit of Javascript to enhance the user experience. All business logic is placed in PL/SQL packages. This is key to making your application easy to maintain, and to reuse the business logic in other Apex applications and from other client tools, such as C# WinForms, Delphi, Java apps, etc.
As for performance, the Apex engine adds little overhead and the response times and scalability of your application depends largely on the quality of your SQL queries (and the data model). Think about it this way: With Apex, the only thing between your user and the database is a thin layer of PL/SQL. It's only common sense that this has to be faster than a typical .NET or Java application that has seventeen layers of complexity (typically including lots of web services and object-relational mapping layers) between the GUI and the database.
不要将业务逻辑放入 Apex 中。 仅将其用于演示。
如果您将代码放入应用程序中，您将无法维护它，并且您将从所有点击中获得 RSI。 我总是创建一个包装层，并且在预言机世界中遵循 Tom Kytes 的建议 - 将业务逻辑尽可能靠近数据。 这也意味着您的 PL/SQL 模块可以由其他系统等调用 - 最重要的是 - 您的应用程序的真正内容将位于直接文本文件中，可以使用您最喜欢的文本编辑器/IDE 进行操作。
简而言之：
不要将您的应用程序逻辑放在 APEX 中。
这就是我的建议。 。 。 。
Don't put buisiness logic into Apex. Use it for presentation only.
If you put the code in the app your will not be able to maintain it, and you'll get RSI from all that clicking. I always create a wrapper layer, and in the oracle world follow Tom Kytes advise - put the business logic as close to the data as possible. This also means that you PL/SQL modules can be called by other systems etc - and best of all - the real meat of your applicaiton will be in straight text files that can be manipulated with your favourite text editor / IDE.
In short:
DO NOT PUT YOUR APP LOGIC IN APEX.
Thats my advise . . . .
Oracle 的 Metalink 支持网站是用 Apex 编写的，因此它绝对可以扩展。 不过，他们现在正在迁移到更新的基于 Flash 的支持网站。 据我了解，他们通过收购另一家公司获得了该平台，而不是为了应对任何 Apex 限制而构建该平台。
如果您希望任何网络应用程序都“超级性感”，您可能需要使用 Flash/Silverlight/Air。 在此基础上，任何基于 HTML 的网站（包括 Apex 网站）都可以使用 Javascript 进行美化。 JQuery 库将包含在 Apex 的下一个主要版本 (4.0) 中，不过您现在可以包含该库（或任何其他库）。
维基百科文章中提到的缓存问题已得到解决，尽管大多数安装仍将图像和脚本放在传统的目录结构上，而不是从数据库中提供它们。
当您被锁定到 Oracle 数据库时，我没有得到本文中的“平台”锁定“con”。 Oracle 可在 Windows、Linux 和 AIX（等等）上使用。 这比 ASP / SQL Server 少了很多锁。
Oracle's Metalink support site was written in Apex, so it definitely CAN scale. They're migrating to a newer Flash-based support site now though. I understand they acquired that platform through an aquisition of another company, rather than building it in response to any Apex limits.
If you want 'super sexy' with any web-app, you'd probably need to go Flash/Silverlight/Air. Under that, any HTML based site, including an Apex one, can be prettied up with Javascript. The JQuery library will be included in with the next main version of Apex (4.0), though you can include that (or any other library) now.
The caching issue mentioned in the Wikipedia article has been addressed, though most installations would still put images and scripts on a conventional directory structure rather than serving them out of the database.
While you are locked into the Oracle database, I don't get the 'platform' lock "con" in the article. Oracle is available on Windows, Linux and AIX (amongst others). That's a lot less lock than ASP / SQL Server.
在我的项目中，我们使用 Oracle APEX 作为系统的内部视图。 它非常适合这个目的。
无需编程。
PL/SQL甚至SQL都是可选的。 因此，我们的 DBA 和操作员可以根据自己的喜好塑造视图。不利的一面是，如果您需要的某个功能没有编程到系统中，则很难添加它。 例如，我们想要对输出进行颜色编码，但无法做到这一点。
我不想在 APEX 上构建面向客户的网站。
关于可扩展性问题，APEX 的一个优点是它是基于 Oracle 构建的。 专注于编写良好的 SQL 并正确设计表，事情应该可以很好地扩展。 我更关心的是如何获得足够的用户来解决可扩展性问题。
On my project, we use Oracle APEX for internal views of our system. It works very well for that purpose.
There's no programming required.
PL/SQLand evenSQLare optional. As a result, our DBA and operator can mold the view to their liking.On the downside, if there's a feature you need which is not programmed into the system, it's very hard to add it. For instance, we wanted to color-code our output and have not been able to do that.
I would not want to have a customer-facing site built on APEX.
On the question of scalability, one nice thing about APEX is that it's built on Oracle. Focus on writing good SQL and designing the tables properly, and things should scale just fine. I'd be more concerned about getting enough users for scalability to be the problem.
非常喜欢从上到下阅读这篇文章，因为感觉就像一场激烈的辩论。 为了提醒一下线程的开头，它的开头是“我相信我们将迁移到 Oracle Apex 以进行未来的开发......”作为 .NET 程序员的 Jack 担心他的管理层的决定，并考虑为 Oracle Apex 寻找反事实最终在公共场合清洗了（所有网络框架的）脏东西。
尽管受害者是 Oracle Apex，但如果争论是在 .net 和 j2ee 专家之间进行的话，同样的情况也可能发生在 .net 或 j2ee 上。 我的观点是所有框架都有自己的优点和缺点。 这就是为什么我们实际上有这么多。 争论生命中哪个更重要（性、食物或水？）是浪费时间，我们自然会在需要时选择最合适的项目。
Enjoyed very much reading the thread from top to bottom, as it felt like a hot debate. To remind the start of the thread it started as "I believe we're moving to Oracle Apex for future development..." jack being a .NET programmer was worried about the decision of his management and thought of finding counter facts for Oracle Apex which ultimately ended up washing the dirty linen (of all web frameworks) in public.
Despite the fact that the victim was Oracle Apex, the same could happen to either .net or j2ee if the debate was between .net and j2ee gurus. My point is all frameworks has their own pros and cons. That is why actually we have so many. Its a waste of time debating over what is more important to live (sex, food or water?) Naturally we select the most appropriate item when that is needed.
如果您想查看在 APEX 中完成的外部网站，我建议查看 Oracle 工具用户组 站点，或 问汤姆。 两者都是大型且经常使用的网站，具有很多定制功能。
您对维基百科文章的印象是正确的。 您唯一需要的编程知识是 PL/SQL。 如果您的站点的大部分内容都是简单的报告，您甚至不需要编写 SQL 查询，向导界面将为您构建查询和输出。 如果您想要出色的客户端工作，您将需要了解 CSS 和 Javascript。 PL/SQL仅用于更复杂的数据验证。
If you'd like to see an external web site done in APEX, I suggest looking at the Oracle Tools Users Group site, or Ask Tom. Both are large, frequently used sites with much customization.
Your impression from the Wikipedia article is correct. The only programming knowledge you need is PL/SQL. If most of your site will be simple reports, you don't even need to write the SQL queries, and the wizard interface will build the query and the output for you. If you want cool client side work, you will need to know CSS and Javascript. The PL/SQL is only for the more complex data validation.
我不同意。 它不仅适合具有少量开发技能的开发人员或 DBA。
实际上，我们使用我们自己的 CSS 模板、大量动态操作和交互（使用 jQuery 和几个框架）、微调的安全性、我们自己的 apex 插件和复杂的 PL/SQL 流程来生成高度定制的应用程序。
当然，我使用的是 apex > 4.0。
因此，如果需要，您可以构建复杂的应用程序（我们每页有多达 100 个不同的流程/验证和动态操作）。 它可能需要强大的编程技能才能在 JavaScript 和 PL/SQL(OOP) 或 Java 存储过程中正确编码 + 良好的 SQL 知识才能使用递归 SQL 和一些有趣的功能定义最多 500 行代码的优化查询。
I disagree. It is not only suitable to devs with a few developing skills or DBAs.
We actually produce highly customized apps using CSS templates of our own, a lot of dynamic actions and interaction (using jQuery and several frameworks), fine-tuned security, our own apex plugins and complex PL/SQL processes.
Of course, I am using apex > 4.0.
So, you can build complex apps (we have up to 100 different processes/validations and dynamic actions per pages) if needed. And it could require strong programming skills to code properly in javascript and PL/SQL(OOP) or Java stored procedures + a good knowledge of SQL to define opimized queries of up to 500 lines of code using recursive SQL and some funny features.