Why is it called "Business Objects"?

  • Thread starter Thread starter G. Stewart
  • Start date Start date
G

G. Stewart

The word "Business" in the term implies some sort of commercial
aspects or connotations. But from what I can see, that is not
necesserially the case at all?

So what is the reasoning behind the term?

Stupid question, I know ... and quite irrelevant in many ways ... but
I really would like to know!
 
G.

From my understanding, Business objects are called "Business" because they
usually encapsulate some process of a business. For example, if you have a
n-tiered site that hosts a shopping site, the middle tier that contains the
"Business Objects" can be used to route shoppers to different portions of
the site depending on their context. If the customer is a consumer, the UI
calls the business objects passing the user context, and the business
objects indicate to the UI that the consumer should be redirected to the
consumer site. However, if the customer is another business, then the
customer is routed to a site dedicated for B2B sales. The point of
separating this logic out from the UI is to allow the abstraction of a
customer and to make the business logic flexible. If another customer type
is determined in the future, all the existing pieces can remain the same,
the only change needed is the business objects.

Hope this helps.

Eric
 
The word "business" can imply any number of things:

\Busi"ness\, n.; pl. Businesses. [From Busy.] 1. That which busies one, or
that which engages the time, attention, or labor of any one, as his
principal concern or interest, whether for a longer or shorter time;
constant employment; regular occupation; as, the business of life; business
before pleasure.
Wist ye not that I must be about my Father's business? --Luke ii. 49.
2. Any particular occupation or employment engaged in for livelihood or
gain, as agriculture, trade, art, or a profession. ``The business of
instruction.'' --Prescott.
3. Financial dealings; buying and selling; traffic in general; mercantile
transactions.
It seldom happens that men of a studious turn acquire any degree of
reputation for their knowledge of business. --Bp. Popteus.
4. That which one has to do or should do; special service, duty, or mission.
The daughter of the King of France, On serious business, craving quick
despatch, Importunes personal conference. --Shak.
What business has the tortoise among the clouds? --L'Estrange.
5. Affair; concern; matter; -- used in an indefinite sense, and modified by
the connected words.
It was a gentle business, and becoming The action of good women. --Shak.
Bestow Your needful counsel to our business. --Shak.
6. (Drama) The position, distribution, and order of persons and properties
on the stage of a theater, as determined by the stage manager in rehearsal.
7. Care; anxiety; diligence. [Obs.] --Chaucer.
To do one's business, to ruin one. [Colloq.] --Wycherley.
To make (a thing) one's business, to occupy one's self with a thing as a
special charge or duty. [Colloq.]
To mean business, to be earnest. [Colloq.]
Syn: Affairs; concern; transaction; matter; engagement; employment; calling;
occupation; trade; profession; vocation; office; duty.
Source: Webster's Revised Unabridged Dictionary

IOW, the word "business" literally means "busy-ness."

A computer application has multiple "parts" to it. The gerneral implication
of the word "business" in programming is that part of the program that
performs the actual "work," if you will, or "business" of creating/fetching
and/or manipulating the data about which the application revolves.
Typically, this is the "busiest" part of the app (the part that does the
most work).

The data layer is generally a passive part of the app, storing data that is
fetched by the business layer. The UI layer is a generally passive part of
the app, which displays data and responds to user actions by talking to the
business layer, which, again, does the actual work, or "business."

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Data - handles storage of information
User Input - handles information presented to and received from users
Business Rules - Handles the rules of making sure data conforms to business
practices, rather than data practices (ie, database/layer handle putting
alphanumerics in an int field, while business rules handle the different
methods of calculating tax in different countries/states, et al)

Why business? The majority of applications are business related. This does
not necessarily mean "doing commercial business" but rather "these are the
rules necessary to calculate a correct answer in our Enterprise/Business".

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************
 
IMHO... OOP was billed as a way of "modeling the real world entities". this
was too much for managers. Afterall, what they want done is soo much more
important to be just called entities. So they came up with the buzz word
"Business Objects" when in reality it's just modeled entities with
encapsulation. Business rules are part of the model, a timesheet object
should have a approve(), submit(), validate() set of methods... they are
business rules if you wanna call them that, but they along with the class
that contains those methods is simply a model of a timesheet entity.

when the going gets tough, invent a buzz word and it will buy you another
month or two.
 
sorry all, i'm in a anti-manager anti-buzzword frenzy today.

during the classic asp days i wrote asp for the presentation tier, java with
javareg for the middle tier (because i dispise vb6 and not terribly big fan
of c++ com writing), and sql server for the data tier. in that case the
java classes would be considered the "business objects". In real world, no
nonsence talk, you would say GUI, Libararies, and database... you know,
terms that programmers learn on day one and have no confusion about. And my
previous post is incorrect in a way. business objects dont "have" to be
done with OOP in mind, i've seen it on other projects at least LOL. but in
reality and considering where i started (classic asp), the Libraries or
"business objects" was where i had free reign to create objects with
inheritance and all the benifits of OOP was where the application really
was. the ASP was only a GUI slapped ontop of the libraries.

so... that's why i mislabeled "business objects" as OOP. I think that
comparison is, and at least should, be right though.
 
Back
Top