Talk:Business object

Opening heading

Good business objects will encapsulate all of the data and behavior associated with the entity that it represents. For example, an order object will have the sole responsibility for loading an order from a database, exposing or modifying any data associated with that order (i.e. order number, the order's customer account), and saving the order back to the database.

With the statement above it assumes that all BO models must encapsulate behavior with alongside the data.

In the real world of enterprise object oriented data modeling using Business Objects, this is an unrealistic or even dangerous design goal.

Business Objects should first and foremost encapsulate the Data. Business Objects can encapsulate some common behaviors but should never encapsulate behaviours that are not global (used by all implementations of the Business Object template). In my experience, it is common for Business Objects to contain no common behaviors and all behaviors are modeled externally.

I suggest that we put some extra text explaining such models rather than making some blanket design comments based on smaller system development vs the real world enterprise application deployments.

Timothy C. Quinn 19:17, 29 December 2006 (UTC)

I am pretty sure I disagree with Timothy about usage and design of business objects, however, I am sure we agree that giving an opinion on what makes a Good Business object is not necessarily part of the definition and should be removed or rewritten.--Joseph Reddy 18:50, 25 July 2007 (UTC)

Business Object design

I agree with Timothy. Putting process that does not belong to a data object into that data object produces over-complex code that's more difficult to modify - let alone reuse. The only behavior that should (imho) be in a data object is CRUDLV - create, read, update, delete, list, and validate. None of these should ever refer to the domain process of creating etc. - rather (for example) the semantics of "create" should include only validating the data provided and, if correct, committing it to some persistent store. In my book "Cooperative Business Objects" (McGraw-Hill 1994), I placed processes that operated on data CBOs (cooperative business objects) into process CBOs. The separation between data objects and "behavior" objects was much more fully developed in two books I co-authored: "Building Business Objects (Peter Eeles and Oliver Sims, Wiley 1998) and "Business Component Factory" (Peter Herzum and Oliver Sims, Wiley 2000).

Business domain?

"Business objects are objects in an object-oriented computer program that represent the entities in the business domain that the program is designed to support."

Please define business domain. Maybe it is synonymous to application domain? Thanks, --Abdull (talk) 18:37, 17 February 2010 (UTC)

Horrible design: business objects responsibles of theirselves

I agree too with Timothy. I get angry a lot of times when I find real-life implementations which are based on putting any kind of behavior in business objects.

Why? Because business objects are real-world entities, meaning these are representing some concept or thing. That is "a business object must not be a functional entity", otherwise domain model is a spaguetti code.

A behavior is a member of a model.

CRUDL (_create, read, update, list_) should be a set of behaviors within a repository and validation in some interceptor somewhere before any process gets into business layer.

Another situation you find in some real-life projects is business objects proxying models. That is macarroni code.

I will be thinking this article should be revised to explain a more accurate "business object" definition.

—Preceding unsigned comment added by MFidemraizer (talk • contribs) 16:13, 7 April 2010 (UTC)

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: Page moved. Airplaneman ✈ 21:37, 13 December 2010 (UTC)

---

Business object (computer science) → Business object — This is the only notable use of business object, and a hatnote can disambiguate the company Business Objects. Pnm (talk) 00:20, 5 December 2010 (UTC)

• Support, clear.--Kotniski (talk) 10:59, 13 December 2010 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Function

The function section and in general the overall description of a Business Object as presented here are contrary to the expert sources cited. In fact "Design Patterns" does not introduce the concept of a "Business Object". Rockford Lhotka's book discusses business objects as encapsulating behavior including but not limited to.:

• Type, instance, method and property authorization for CRUD operations.
• Data validation.
• Business rules (computation).
• Interfacing with the Data Access tier for persistence and object hydration.
• Undo/Redo functionality.
• Special serialization cases.

"Core J2EE Patterns" supports Rockford Lhotka's definition of a business object in concise, pattern oriented terms.

The definition as being provided here is synonymous with a Data Transfer Object or an Anemic Domain Object when in fact, they are completely different concepts.

References