 |
|
|
|
|
|
In the previous two chapters, you learned the basics of creating individual PL/SQL program units.
As you might imagine, a complete application could be composed of many, many program units.
There may be program units that you want to use in more than one application. And you might
want to find a way to define program units so that the implementation details are separate from
the way the units are called.
You can accomplish all of this with PL/SQL packages.
What Is a Package?
APL/SQL package is a way to group sets of program units together. With the exception of a few
additional keywords, the syntax for creating PL/SQL packages is identical to using PL/SQL to create
program units.
The basic difference between packages and standard program units is that a package is divided
into two separate modules: a package header, or specification, which lists the interface to a set of
program units and contains any variables or constants that are visible to the world outside of the
package, and a package body, which contains the implementation of the program units listed in
the header, as well as any variables or constants that are only visible to the programs in the package.
A package body can also contain program units that are not listed in the header.
The syntax for creating the package header is as follows:
CREATE [ OR REPLACE ] PACKAGE package_name
IS
declaration_section
program_units
END package_name;The declaration section has the same syntax as the declaration section for a PL/SQL procedure or function.
The program_units section lists the procedures and functions defined in the package body that are
visible to users of the package.
The syntax for creating the package body is as follows:
CREATE [ OR REPLACE PACKAGE ] BODY package_name
IS
declaration_section
PROCECUDRE/FUNCTION program_name
.
.
.
END package_name;
As with the package specification, the declaration section of the package body is just like the declaration
section for a PL/SQL procedure or function. The difference between the variables, constants, exceptions,
and cursors declared in the package body is that these objects are not visible or accessible to users of the
package.
The code for the procedures and functions within the package is the same code you would use for a
standalone version of the program.
You can declare PL/SQL program units in the package body that are not listed in the package specification,
but, as with the declarations, these units will not be visible to users of the packages.
The definitions of the procedures and functions in the package body must exactly match the definitions
of the matching units in the package specification. If there is a mismatch in terms of the number or data
type of parameters, the PL/SQL compiler will interpret the specification and the implementation in the
body as two separate units, resulting in a resolution error if you call the unit by name.
You could combine both of these in a single text file, but typically you would keep them in separate files.
For reasons discussed in the next section, you will probably be changing the information in the package
body more frequently than the specification in the package header.
Impact of Packages
From a consumer’s point of view, having a standalone procedure or a procedure that is a part of a package
is not that different. You would call either one in a very similar manner—the only difference would be
that you would have to preface a call to the procedure in a package with the package name, as in
promo_package.initialize()
for the packaged procedure versus:
initialize()
for the standalone procedure.However, there are several significant differences for you, the developer, in using packages rather than
individual program units.
Organization
As a developer, you seek to be as efficient as possible. One of the ways you can improve your efficiency
is to reuse existing code. The more discrete and modular a particular program unit is, the more flexibly
is can be reused. For instance, which of the sets of procedures in Figure 17-1 is more like to be reused?The option on the right will probably be reused more frequently, since the logic is more modular. Another
application does not have to require logical steps 1, 2, and 3—any step can be called independently,
which makes the logic more flexible.
The downside of this type of modularization is that it leads to large numbers of individual program units,
which can be hard to track. With a PL/SQL package, you get the benefits of the fine-grained functionality
of smaller program units and the ease of discovery of larger units.
Visibility
Perhaps even more important, packages give you a way to only expose interfaces and information that
you want to make visible. A user can only access the information in the package header specification.
Any details of implementation and variables used to implement functionality within the package body
can be invisible outside the package body, so you can also define variables and constants within a package
body to hide them from external consumers.
The ability to have publicly exposed methods and variables and privately protected methods and variables
gives you two advantages. The separation between interface and implementation means you can maintain
the way procedures and functions are actually performed, with the code in the package body, without
worrying about how those changes will affect their use by other programs. In addition, you can protect
data and program units from the outside world. No one outside of a package can get to the data and
program units inside the package, which can help in implementing security in your applications.
Scope
The separation between a package specification and the package body introduces another level of scope
into your design scheme. With standalone PL/SQL programs, you can use parameters to pass information
logic1
logic2
logic3
logic1
logic2
logic3
381
PL/SQL Packages
to and from the program unit from the outside world, or declare them within the body of the program
unit, which kept them private. With packages, you have three levels of scope:
? Package declared procedures, variables and constants, which are available to everyone—inside
and outside of the package
? Package body declared procedures, variables and constants, which are only available to program
units in the package
? PL/SQL program unit declared variables and constants, which are only available within the
program unit
Having more options gives you greater flexibility to declare objects where their scope will be both
appropriate and logically meaningful. Your declarations are protected from outside access, depending
on where you define them.SapereOnLine |
|
|
|
|
|
|
|
ORACLE
|
|
|
|
|
| |
|
 |
|
|
|
|
