DataModules as Business Objects

1
DataModules as Business Objects

• Purpose and Advantage of Business Objects
• Managing Business Objects
• Designing a Business Object

2
Purpose and Advantage of Business Objects

• Encapsulation of identifiable Business Concepts
• Centralization of Business Rules
• Separation of Business Rules from Presentation

Why are these advantages?
3
Purpose and Advantage of Business Objects

• Encapsulation of identifiable Business Concepts
• Centralization of Business Rules
• Separation of Business Rules from Presentation

Why are these advantages?
4
Encapsulation of Identifiable Business Concepts
Advantages

• Forces more thought about what business problems
  are to be addressed by the project and the
  interactions between these
• Organizes and focuses design effort
• Enhanced ability to successfully delegate
  programming tasks
• Enhanced ability to monitor progress and sign-off
  completed tasks

5
Encapsulation of Identifiable Business Concepts
Although in many cases a Business Object will
essentially manage a single database table,
objects should be built around the business
concepts. For example, the Orders object would
manage Orders and OrderItems tables, but must
also handle relations between these and Products,
Customers, Inventory and so on.
6
Hierarchical Business Concepts
Business Objects can, and should, use other
Business Objects. Here, as indicated on the last
page, the Orders object is shown to have
relationships with other objects.
7
Purpose and Advantage of Business Objects

• Encapsulation of identifiable Business Concepts
• Centralization of Business Rules
• Separation of Business Rules from Presentation

Why are these advantages?
8
Centralization of Business Rules
Advantages

• Business rules for each business concept are
  organized in clearly defined objects and units
  instead of fragmented across many units
• Simplifies maintenance and enhancement
• Helps protect data integrity since all access
  must be through these objects
• Easily reused !!

9
Purpose and Advantage of Business Objects

• Encapsulation of identifiable Business Concepts
• Centralization of Business Rules
• Separation of Business Rules from Presentation

Why are these advantages?
10
Separation of Business Rules from Presentation
Advantages

• Presentation can be changed easily since no
  change affects implementation of the rules
• Multiple presentations can be coded without
  re-coding the rules, for example a Windows GUI
  and a Java GUI
• Rules can more often be changed without requiring
  coding changes to the presentation

11
Managing Business Objects

• Ownership
• Affects lifetime of the object. Created and
  destroyed when and by who?
• Sharing
• Can the resources in an object be shared by
  different users concurrently, or are multiple
  instances required?
• Factories
• Centralized Business Object management

Business Objects are subject to the same design
issues faced when designing any object. There is
no single correct way to implement a Business
Object, but there are some typical issues and
common ways to deal with them.
12
Managing Business Objects

• Ownership
• Some Business Objects are needed throughout the
  lifetime of the application, for example, a
  Security Business object to allow checking of
  user permissions as well as log-in and log-out
  methods. In this case, the Application should be
  the owner.
• Most Business Objects are only needed for a short
  time by a particular Form or other Business
  Object. In this case, the Form or other Business
  Object should be the owner.

By simply setting an appropriate Owner, the
lifetime of a business object is automatically
taken care of for you by Delphis built-in
Component behaviour.
13
Managing Business Objects

• Sharing
• If being used by a form that will connect
  data-aware controls, then the same Business
  Object instance cannot be shared among multiple
  forms since the datasets involved can only
  maintain a single state and cursor position. Each
  form must have its own instance of the business
  object.
• If no data-aware controls are involved, then
  there is a possibility of making a business
  object stateless and therefore shareable between
  any number of users. In this case, the Business
  Object should be a singleton owned by the
  Application.
• Each Business Object should be able to say
  whether or not it is shareable. This is most
  easily done by creating a Shareable base class
  and descending such Business Objects from that
  base.

14
Managing Business Objects

• Factories
• The Main DataModule is a perfect place to
  provide management for Business Objects including
  a Factory method for creating them.
• Providing a Factory
• Provides a consistent method for users to acquire
  Business Objects.
• Makes it easy to manage the issues of Ownership
  and Sharing
• Ensures users do not control how Business Objects
  are created and do not need to worry about
  Ownership and Sharing issues.

Every application should have a Main
datamodule that provides application-wide
facilities. This datamodule typically contains a
TDatabase component (or equivalent) to which all
other database components connect.
15
Business Object Example