Talk:Business object (computer science)

From Wikipedia, the free encyclopedia

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 encasulate the Data. Business Objects can encapsule some common behaviors but should never encapsulte behavirours that 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.

hhhhhhhh 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)

[edit] 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).