Documentation Archive Developer
Search
PATH  WebObjects 4.0 Documentation > EOF Developer's Guide

Table of Contents Previous Section

The Enterprise Objects Framework Difference

Today's business applications must embody complex rules of the business, access heterogeneous corporate data in database systems from multiple vendors, and offer different front ends to meet the needs of users in all different parts of the business. This is a tall order to fill, but Enterprise Objects Framework meets all these needs. It provides database independence, transparently maps custom business objects to database tables, and binds business objects to user interfaces.

Where Does Business Logic Go?

The biggest difference between Enterprise Objects Framework and other solutions is where you put business logic. One approach is to implement business rules in the user interface, as you do with 4GL tools. Problems with this approach include:

Another approach is to implement your business rules in the database-with stored procedures, rules, constraints, and triggers, for example. This approach also has problems:

A third approach-the one that Enterprise Objects Framework takes-is to put business rules in business objects, called enterprise objects. By applying good object-oriented design principles, this approach provides the advantages of encapsulation, reuse, and a more natural model of the real world. For example, suppose you're writing an application for managing a video rental store. The business logic for such an application might include the rules:

With Enterprise Objects Framework, you would implement these rules in enterprise objects such as Customer, VideoTape, Rental, and Fee.

What Doesn't Go in an Enterprise Object

Deciding what code to leave out of your business objects is just as important as deciding what code you leave in. To maximize the reusability and extensibility of your objects, they shouldn't embed knowledge of the user interface or database alongside the business logic. For example, if you embed knowledge of your user interface, you can't reuse the objects because each application's user interface is different; and if you embed knowledge of your database, you have to update your objects every time you modify the database.

If not in the business objects, then where does this knowledge go? It's handled by Enterprise Objects Framework as shown in Figure 1.

Figure 1. The Enterprise Objects Framework Approach

The Framework provides a database-to-objects mapping so your objects are encapsulated from the database, and it provides an
objects-to-interface mapping so they are encapsulated from the user interface. This approach enables you to create libraries of enterprise objects that can be used in as many applications as you need, with any user interface, and with any database server. You're able to concentrate on coding the logic of your business while the Framework takes care of the rest.

Table of Contents Next Section