Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Programming Jakarta Struts, 2nd Edition [Electronic resources] - نسخه متنی

Chuck Cavaness

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








6.2 What Is a Business Object?


This question may sound a little too
simplistic for a book on Struts. However, the term
"business
object" has many connotations, and some developers
use it when they really mean something else. A business object (BO)
is simply a software abstraction of a real-world entity. It
represents a person, place, thing, or concept from the business
domain. So, concepts such as items, orders, and customers are all
business objects from the Storefront business domain.

Business objects consist of state and behavior. The
OrderBO, for example,
is aware of information relating to a single customer purchase order,
including price, tax, and order status. An OrderBO
also should know who the customer is and be able to provide this
information. Having both state and behavior is an important criterion
for a class to be considered a business object.
Let's examine a few other business object
characteristics.


6.2.1 Requirements for Business Objects


For a class to be considered a business object, several conditions
should be met:

  • Consists of state and behavior

  • Represents a person, place, thing, or concept from the business domain

  • Is reusable


Business objects also can be grouped into different classifications.
Generally, there are three types:

  • Entity business object

  • Process business object

  • Event business object


Probably the most familiar, an entity BO
represents a person, place, thing, or concept. These usually are
extracted straight from the business domain by considering the nouns
in the business. Again, these are concepts such as customers, orders,
items, and so on. In an EJB application, these are modeled as entity
beans (hence the name). In a more traditional web application, these
may be regular JavaBeans that contain the state and behavior of the
business application.

Process BOs
represent business processes or workflow tasks within an application.
They usually are dependent on entity BO objects and are the verbs of
the business. In an EJB application, these normally are modeled as
session beans or, in some cases,
message-driven beans. In a non-EJB application, these may be regular
JavaBeans that contain specialized behavior to operate as a manager
or controller for the application. Even though these types of
business objects are used for processing workflow, they still can
hold state for an application. With EJB, for example, there are
stateless and stateful session beans.

The final category of business object is the
event BO. An event
BO represents some event in the application (exception, alert, timed
event) that causes or is generated by some action in the system. In a
Java Swing application, for example, when you press a button, an
event is raised notifying the underlying framework so that an event
handler can handle the button press.


6.2.2 The Importance of Business Objects


Using business objects in an application has
several benefits. Probably the most important is that business
objects provide common terminology and ideas that can be shared
across an organization by technical and nontechnical people alike.
Because they represent real-world concepts and ideas, they are very
intuitive and should make sense to the entire organization. If
multiple applications from the same business domain exist,
it's likely that the same business objects exist
across the application boundaries. This reuse of information and
behavior allows for faster application development and reduces
redundancy.

Business objects also have the ability to evolve with the
organization through modifications to the original object or through
proper specialization. This is very important because as an
organization changes, the information and behavior must adapt and
change with it.

Finally, business objects have well-defined interfacesnot
interfaces in the Java sense, but a clear and cohesive set of
functionalities. The internal implementation should be hidden from
the client to protect the callers from changes to the implementation
details. For example, suppose you have a business object that uses a
java.util.ArrayList. Instead of exposing the type
ArrayList, you should expose
java.util.List. If the implementation changes
internally from ArrayList to
LinkedList, the caller will not be impacted
because the client is programming against the List
interface, not the implementation class.

By now, you should be fully aware of the importance that business
objects have in an organization. They are present in all but the most
trivial applications. You also know that they contain state and
behavior that, in most cases, acts on that data. So the next
questions should be, where does that state originate and where does
it go when the application is stopped? This leads us into the topic
of object persistence.


    / 181