- Packaged Code: PL/SQL - With this method you take, possibly, an existing application and "skin" it with APEX. Using APEX's built in Form based on a Procedure wizard, this is quick and painless. You spend most of your time just moving buttons around to suit your needs. Maybe I've been reading AskTom for too long, but that's the general approach I take.
- Declarative - Using all the built-in functionality of APEX which creates all kinds of objects (triggers for example) that will be managed by APEX. This is probably most geared towards the power users who don't yet have the ability to write a lot of PL/SQL but have a pretty good understanding of building an application.
- Hybrid - This approach mixes and matches the 2 previous approaches. You use packaged code for the bulk of your application and the declarative functionality within APEX for everything else. For example, the multi row INSERT/UPDATE/DELETE. I can write that whole thing out using TYPEs in PL/SQL, populate an APEX collection, convert that collection to a TYPE and then pass that TYPE back to PL/SQL...but do I want to? It saves a boat load of time to use the built-in features. Ultimately it depends, of course, on many different factors.
Mr. Kyte on where to put data, in the DB or in the web tier:
They belong right next to the data - allows you flexible access to the data - you can build a new application WITHOUT reinventing all of that stuff.I love APEX, but will it be around forever?
where does the logic to display a bunch of numbers in a pie chart belong? In the application.
where does the logic to ensure that if X=0, then Y must be >= 0? That belongs right next to the data.
So, programming logic - some of it in the application - user interface code, user interaction code, error handling, display of data, report generation - in the application.
Much of it in the database - security, access control, data integrity.
4 comments:
The Apex 4.0 enhancements suggest that it will go for a few years yet [at least], which is practically forever in computing terms.
The Apex listener should also be able to put it in a few places that were uncomfortable with either the Oracle HTTP server and/or the embedded PL/SQL gateway.
I certainly don't want it to go anywhere. I suspect that if it did disappear, I would keep copies of it around so I could still use it. But I agree, it's not going anywhere in the near future.
Instinct and old-school dev 2000 experience says don't go near apex for serious work.... but every tool has a use. In fact, only recently I hacked 420 lines VBA module/class goodness and created a schema exporter/data loader in Excel. This was only after I had created 4000 lines of Java using POI to do the same thing. :) that said, I can do in Rails in 5 minutes what takes an hour in apex. Still, I love Apex too :)
@EscVector: I suspect that has more to do with your lack of experience in APEX than with the power of Rails.
When building any type of data oriented solution, APEX is the faster way to develop.
Even performance and scalability aren't issues. There are more than enough serious examples of APEX out there.
Post a Comment