| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: POWERBUILDER vs FORMS 4.5
Allen,
Your decision will need to be based upon what sort of project you are planning to use Dev/2k or Powerbuilder for. The issue is not which is a better tool; it is that they belong in two entirely different classes of tools. Dev/2k is a true 4GL, while Powerbuilder is a GUI Development Tool. And when it comes to applications development 4GLs and GUI Development Tools are appropriate for entirely different types of applications and environments.
Powerbuilder is a first-generation C/S Tool, and is used widely to develop graphical, event-driven apps that run on the client platform. It incorporates a GUI, customized prodecural logic, and transparent access to disributed data via ODBC. It (and other 1st-gen's) is well-suited toward the development of light, decision support applications and other user-friendly, desktop applications that do not require a high degree of data integrity or logical correctness, aswell as for quick prototypes (although VB is even quicker and easier to use toward that purpose).
Powerbuilder and other tools of its ilk allow you to build applications with greater ease and facility, and greater control over the GUI environment. They're easy and quick to learn, and given their limited scope, won't allow you to shoot yourself in the foot too badly. However, you'll be limited to small-scale, two-tier C/S apps with only ODBC support of DBMS connectivity.
The drawbacks of Powerbuilder and its like include:
--Lack of scalability to enterprise-scale applications Scalability requires support for OLTP, distribution of processes, high data integrity, and rigourous analysis and design techniques. PB and its like are incapable of meeting the above requirements; they generate applications that run only on the desktop, and do not support large numbers of on-line users a high degree of data integrity, or the use of rigourous A&D methodologies.
--Poor on-line performance
PB and the like do not provide adequate response time for applications that
incorporate complex procedural logic or mulitple database queries. This
lack of on-line performance is caused by the fact that processing cannot
be split between client and server platforms, and that all generated code
must be interpreted at run-time. The use of interpretive code permits
prototype apps to be demonstrated rapidly to end-users; however, it imposes
a significant performance penalty at run-time.
--Lack of support for distribution of processes PB and the like generate code only for the client; they DO NOT support application partioning between the client and server platforms, or the automatic generation of stored procedures and triggers. To obtain adequate on-line performance with PB and the like, it is often necessary to recode selected client processes in the form of stored procedures on a server. Since the generation of stored procedures and triggers are not supported PB and the like, these will have to coded in the language of the installed DBMS, such as PL/SQL for Oracle, TransactSQL for Sybase, etc. This will require your developers to learn two languages. Also, your developers are forced to decide early in the design process which processes will run on the client and which will run as stored procedures or triggers on the specified servers. If reallocation of processes subsequently becomes necessary due to operation inefficiencies, the distributes procedures must be rewritten by hand for the new platform. This severely restricts the developer's ability to allocate processes to appropriate platforms for maximize performance.
--Limited support for middleware
PB and the like don't provide the infrastructure required to support high-vol
transaction processing, security, RPCs, global naming, version control,
configuration mgmt, and network management. This is otherwise known as
middleware. Examples include SQL*Net for Oracle, Open Client and DB-LIB for
Sybase.
--Lack of support for OO business modelling
PB and the like use an early, rudimentary form of OO technology. You can
organize objects, such as DataWindows, into class libraries, based on
hierarchies of GUIs. Each object encapsulates a GUI, db access stmts, and
procedural logic. Lower-level objects inherit control structures from
higher-level objects. However, there is a growing need for more
generalized
class library structures that don't limit the library to hierarchies of GUIs.
More advanced, OO business modelling techniques enable developers to specify
applications from a knowledge base of low-level resuable components. PB and
its ilk don't support this.
--No common object repository
Without an object repository, PB and the like don't support team-driven
development. It's not easy to maintain consistency, quality, etc. with
project-team development using PB and the like. It's a pain. You're forced
to use 3GL configuration management tools such as MKS to manage your code, and
this is serious mismatch for when you need to write 4GL applications.
Developer 2000, Uniface, Dynasty and the like are among the Second-generation C/S Tools. These are strategic, enterprise-wide tools that overcome the limitations the first-generation Tools. These 2nd-gen tools provide an intutive ,graphical development environment, high performance, scalabilty, transparent linkages to middleware, and tight integration with rigorous CASE specification techniques.
These products are designed to support complex, enterprise C/S
that can run the
organization. Examples include on-line order entry systems, on-line trading
systems, claims processing, customer service, reservation systems,
manufacturing systems, inventory control, etc., etc., etc. These apps are
transaction-oriented, often move money or update inventory, and are vital
to the operation of the business.
These products support
With such tools most development staff do not require knowledge of specialized code needed to support different GUIs, SQL-based DBMS's, transaction management, and network communications, error handling, recovery and security. They'll have less low-level control of these features but have to deal less with them as these are abstracted. The ads you see in the magazines are true: what you'll write in the 71 lines of code with PB or Momentum you'll write in 0 lines of code with Oracle Dev2k, Uniface, Dynasty, etc. These tools also provide a set of intelligent editors that guide the analyst through all the details of building the components of the transaction processing system. The editors check for syntax errors, and perform semantic checks to through all the details of building the components of the transaction processing system. The editors check for syntax errors, and perform semantic checks to ensure that the transaction processing operations are logically correct.
The drawbacks of these tools include:
--Learning curve
These powerful, flexible tools are by nature more difficult to learn than
the GUI tools. You'll code less but you'll have to understand more; i.e.
be a better developer. You can shoot yourself in the foot if you don't
know what you're doing.
--Complexity
The 2nd-gen's can be at times overwhelming with their complexity at times.
Again, this is the nature of the beast. Your tools can do a lot more, and
as such there are more tool components to consider. Tasks such as version
migration can be more challenging to accomplish.
--Occasional user-unfriendliness
Dev2k is a good example here. Sometimes Dev2k can be a pain with its
clunkiness here and there. And it and Uniface and Dynasty and the rest
are not always easy to use. Thats the tradeoff of greater power and not
having to deal with SQL. Again, one has to step back, look at the big picture
,and be a better developer when working with these tools. This is often the
basis for going with a tool like Powerbuilder or SQLWindows. It's the
wrong reason.
--Do not directly support GUI Objects and Controls as do GUI Dvpt Tools With GUI Dvpt Tools, you can really dig into low-level manipulation of MDI Windows, OLE Objects, Custom Controls and DDE in MSWindows, directly through the Tools themselves. With 4GLs and their positioning for platform independence and flexibility, such direct control is not supported, and the developer will have to utilize custom modules written in a 3GL (e.g. DLL written in C for MSW) utilizing the 4GL's API. This makes for some more work on the developer's part if such support is important.
What this gets down to is if you're
building an enterprise-scale IS, PB, SQLWindows and the like are NOT for
you. You should go with Dev/2k or UNIFACE (UNIFACE if you want improved
portability of apps across multiple platforms, and superior model-driven
development). If you want to build a small-time, one-platform application
where you'll need to have 3GL-like control over the GUI environment but for
which you don't expect to scale for use beyond 2-3 years, don't need
referential integrity, model-driven development, etc. go with PB,
SQLWindows, etc.
If you want to get an
enterprise-scale solution yet want a small-timer to
prototype with, get Delphifor the prototyper. Its cheaper, easier to use,
and far more powerful for prototyping than PB or SQLWindows.
I hope this information is of some help to you.
Regards,
-Charlton.
>We are debating on whether POWERBUILDER or FORMS v4.5 (DEVELOPER 2000)
>would fit our needs better as a frontend application developing tool
>in a Windows environment on client workstations to our ORACLE server.
>We are presently running ORACLE on OS NOVELL on a 486 60Mhz PC Server,
>but possibly in the future could move to a UNIX box. We will be
>developing 2 or more applications in 1996 and have 2 - 3 developers.
>
>We presently have DEVELOPER 2000 with FORMS but have not done any
>developing with it. We would need to purchase POWERBUILDER.
>One of my associates seems to believe that POWERBUILDER is a better
>product (His reasons - its been around for a long time - has a good
>reputation - POWERBUILDER is compatible to many other tools).
>He seems to have convinced my boss to go with POWERBUILDER.
>Training and coming up to speed is also a issue. We have no
>experience on either, so would need training on both ( although
>I am familiar with ORACLE and SQL). We both are completely new to
>POWERBUILDER so would need to be trained in it..
>
>I would appreciate your opnion (especially if you have developed
>applications with both FORMS and POWERBUILDER or have gathered
>comparison facts between them). I realize this list might be
>somewhat biased for ORACLE FORMS. In your reply, please
>attempt to give good reasons based on your experience or facts you
>know.
>
>THANK YOUAllen G. Wells (612)627-5492 FAX: (612)627-5479
>MN Dept of Health, Enviromental Health Division
>Internet: Allen.Wells_at_health.state.mn.us
+-------------------------------------------------------------------------+ | charlton barreto barreto_at_Biz.net * active * | | software engineer charlton.barreto_at_ebay.sun.com | | sun microsystems computer company cbarreto_at_ocf.berkeley.edu | +-------------------------------------------------------------------------+| TCHAR szDisc[] = _T("These words are my own; I do not speak for Sun."); |
+-------------------------------------------------------------------------+Received on Sun Jan 14 1996 - 17:06:13 CST
 |
 |