Database Objects Advantages
Database Objects provide a number of advantages, including:
- Database Independance
Database objects are built from the ground up to be database independent -
they do not rely on the features of a specific underlying database to provide
their functionality. This allows an application build using database objects to
be ported from one database platform to another in literally moments, providing
the potential for great scalability.
- Automatic Connection Handling
- Declarative Referential Integrity
By embedding access logic directly in the database object, you can achieve
the same advantages as using stored procedures for accessing a database without
the platform-dependence. Referential integrity becomes database independent, and
complex relationships between database objects become portable. For example,
business rules can be integrated into the database object, so that all
applications accessing the object are assured of following the established
rules.
- Multi-Level Validations
- Avoiding embedded SQL
Using database objects allows an application to avoid embedded SQL and
it's maintenance difficulties and system dependencies. Applications simply
interact with other Java objects, allowing the design of a system to be
entirely object-oriented.
- Security, and much more.
Every interaction with a database object can be secured, and the security
data is easily maintainable via Expresso's built-in capabilities.
By using Database Objects in your application, you can take advantage of all
of these capabilities without writing additional code.
Database objects provide a functionality
that is similar to an extension to the Entity EJB specification, but do not
require EJB's to be used, with the attendant complexities of an Application
Server. Where EJB's are used, database objects can be implemented as Entity
EJB's easily, allowing scaling both up AND down in size and complexity.
Expresso Framework provides ancestor objects for Database objects (DBObject),
which provide means for defining attributes (columns to be stored in the
database), defining keys, specifying relationships to other objects (referential
integrity) and defining default values and valid values for columns (e.g.
multi-valued columns, such as Yes and No, etc).
Database objects also provide all basic operations,
such as add, update, delete, search and retrieve.
Methods are provided that allow objects to
be searched for either by primary key or
by any combination of field values (wild-card
searches), and searches can be set up to
return only a specific database object or
a Vector of database objects. With a few lines of code you can create a
database object that includes all of this
functionality, allowing applications to be
built extremely rapidly.
Database objects map capability between Java objects and a relational database
(RDBMS) in a standard an highly extensible way, so that the objects themselves
can be used in your application, removing the need to embed SQL code directly
into your Java applications.
Many enterprise applications require access to the data stored in multiple
databases. The "Database Object Mapping" functionality in Expresso allows a
developer to define a new DB context to describe a particular database, and then
associate particular dbobjects with that DB context so that when that object is
manipulated, it is always operating against the correct DB context.
Expresso applications can now be run with a "split context", with one
database handling the control tables (such as USERLOGIN, etc.), and one database
storing the application data (like a data repository, shared by a few different
Expresso applications). This allows you to create different "looks" or "views"
to the same data, with completely independent logins, security groups, etc. The
bottom line is that now you can specify many different database contexts, and
define DBObjects as belonging to one of these contexts at the schema level.
After this step, the system will always look to the right database when you use
that DBObject..
DBObject code can be generated from an existing database, or the database
required for an applications DB objects can be automatically created, making
working with DB Objects in either new or existing environments extremely
straightforward.
A servlet is supplied with Expresso that provides immediate
database-maintenance capability for any database object (in fact, for any
database table through the use of AutoDBObjects). This facility uses the
security defined for the object and automatically generates forms to add,
update, delete and search for data in the underlying database tables.
Security can be specified for any operation on any database object in a
database-independant layer of Expresso, again making your security portable
between database engines and immediately usable to any Expresso application,
including the DBMaint servlet discussed above.
Changes made to a database table have no affect on code using the database
object, as these changes only need be made to the database object itself. This
decreases maintenance burden on code and enhances portability between different
databases.
Database objects allow fields to be defined that are calculated by any
specified method (and not stored in the database). They allow referential
integrity (the relationships between objects that must be maintained (e.g.
invoice master/detail) to be defined in a database-independant way, they allow a
set of valid values to be defined for a field and verify field validation
against that list automatically, they allow serial number fields to be
automatically assigned correct values, and much more. Please see the detailed
documentation in the Expresso developer's guide for details.
A special extension of the DBObject, MultiDBObject, is provided which can
also span multiple tables. As it is often necessary to deal with Join relationships
between tables in relational databases - the MultiDBObject exists to handle
this. If a DBObject is analogous to a table, a MultiDBObject is analogous
to a view (of joined tables).
For example an Invoice object might also contain data for the detail items
on an invoice, which are stored in an "INVOICEDETAIL" table -
rather than having many InvoiceDetail database objects, which might create
undue performance load on the server. Instead, the Invoice object would
contain methods for manipulating invoice details, such as "AddDetail".
Database objects also make "virtual fields" easy to produce -
such as a "Total" field, which is calculated on the fly, not
stored in the database itself.
Many of the same operations available to DBObjects are available to
MultiDBObjects - including searchAndRetrieve(), clear(), setField (although with
different arguments), etc.
Collections of database objects can be gathered
together into a "Schema" - for
example, all of the database objects required
for the Invoicing application could be gathered
into a Schema. This schema can then be used
to automatically generate the database tables
required by each of the database objects
(as well as setting up required configuration
values and reports). This makes installing
the application on a new server a matter
of minutes, and eliminates the need to tediously
create the database tables individually.
AutoDBObject
The AutoDBObject is the easiest way to get access to your database tables
and can be very valuable for prototyping your application. AutoDBObject
can populate its fields automatically from the schema information of its
target table. This allows an AutoDBObject to be instantiated and used to
access a table without any coding at all!
The Expresso Framework also contains server-side
objects without data, similar to (and soon
to be compatible with) Session Enterprise
JavaBeans.
Expresso in a non-J2EE environment provides
pre-built services and components for putting
together database-based web applications.
The way we approach the J2EE environment
issue is that Expresso applications should
be able to scale, fairly "painlessly"
from a non-J2EE environment to a J2EE environment.
This actually involves very little redundancy
overall, although there is certainly some
overlap. In the areas of overlap, our goal
is to not re-invent any wheels, but to provide
app-server independant alternatives to things
that might bind an application to any single
application server implementation.
For example: many application servers provide
a connection pooling mechanism. So does Expresso.
Expresso's connection pooling, however, is
not tied to any specific implementation by
a J2EE-server vendor, so your application
is not tied either. It also provides a consistent
set of features that your application can
depend on being there that go beyond the
typical services available in a J2EE compliant
JDBC2.0 connection pool - for example, reconfigurable
type mapping, error message translation,
timeouts, tracing, multi-database capability
and connection testing, to name a few.
In the area of database objects and entity
beans, db objects give a much more "filled
out" implementation of a database-aware
object. They provide, for example, for db
object-level referential integrity, are integrated
with the automatic database maintenance servlets
that are part of Expresso, can be automatically
generated (bi-directionally), provide built-in
methods for multi-valued fields, automatic
change logging on critical objects, validation,
and so forth. So, we think of entity EJB's
as a mechanism for using DBObjects in a distributed
environment, not as a "competitive"
capability to dbobjects. DB Objects also
do not have the inheritance problems that
exist with Entity EJB's.
Security is another area: All J2EE servers
provide some means of administering security,
both for session and entity beans. Expresso's
security is explicitly designed to be stored
in a database, and can easily be extended
to integrate with other models (e.g. LDAP
integration is in the works already). It's
tight integration with database objects,
and it's existing thin-client administration
capabilities mean again that an application
can have superior functionality right away,
and avoid any vendor-specific features. Expresso's
security layer allows web-based administration
of dynamic security that is in addition to
& complementarty to EJB container's declarative
(deployment-descriptor) based security.
The Transaction package (probably a bad name
for it) is probably the least understood
and quite possibly the most powerful area
of Expresso. Again, we see session EJB's
as a perfect mechanism to provide Transaction's
functionality in a distributed way. The finite-state
machine design of Transactions is an extension
of the sesion bean's functionality, and is
again tied into the security model. The new
enhancements being done now to the transaction
package provide a much easier means of tying
your business logic to UI-independant interaction
with the user than having to create custom
JSP's or servlets to do the same thing. The
way Transactions can be used with TrxActionServlet
and TrxServlet to "automatically generate"
user interfaces (including the new XSLT UI
generation in the Expresso XML project) allows
an application to be prototyped and tested
without any though to the UI code at first,
then customized at the UI level completely
independantly of the business logic, promoting
good application design (MVC architechture).
Logging: A singleton-based multithreaded
logging service that is independant of any
specific EJB implementation is provided by
Expresso's logging classes.
Event Handling: The built-in integration
of email event handling provides immediate
administrative notifications to an Expresso
application, whether in an EJB environment
or not. This is again something that would
have to be built without the framework.
Job Handling: Even in an EJB environment,
Expresso's ability to "queue" jobs
for handling on the server side is valuable
for longer tasks than are suitable interatively.
E.g. an accounting system might need to "post"
thousands of entries in response to a user
request. This is an ideal use of the Job
object in Expresso, and applies equally well
to EJB environments.
I'm sure you see where we're headed - J2EE
provides a good environment to host applications,
but it doesn't provide pre-built tools to
snap business logic - Expresso helps to fill
the gap between J2EE's capabilities and your
finished application, while still allowing
the ability to scale both up (EJB/J2EE) as
well as DOWN (e.g. non-J2EE environments)
with the same applications.
For technical information about how to use dbobjects, please refer to the
Expresso Developers Guide (EDG) or the Javadocs.
|
