bigred said:
Assuming you're not talking about a company or product called Business Objects, it's one of those buzzwords that make my teeth stand on edge. It comes from a 1990s tradition of how systems should be designed. All the word that have been used in this tradition are ugly and/or misleading, and it has been over-pseudo-formalized to a counterproductive degree.
The idea is reasonably sound, however. That is that different parts of the code should be kept somewhat separate, as it makes things easier to maintain. Assuming an object-oriented design (which is misleading, as most of these systems are more what I call class-oriented than object-oriented), there should be objects to control the database or file system, objects to interact with the user, and objects between them that do the actual logic of the program. The last group is called "business objects."
This is an ugly name, but it isn't as ugly as the names of the other layers, which are "persistence" and "presentation," except when the latter is "user interface." There are also "system" objects, which is kind of ugly and misleading but at least has a long history.
The persistence and presentation objects can talk to the system objects, but not the same subset of system objects (one of the ways that the metaphor breaks down.) The persistence and presentation objects should not talk to each other directly but only through business objects. The business objects should not talk to the system objects.
Take a spell checker on a word processor for example. The business objects hold all the structure of the document and will ask the persistence objects whether a word is in the dictionary. If it isn't, they will tell the presentation objects to put an irritating little red squiggle under the word, the one that appears every time you use a proper name.