"Business" objects?

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:

> Active Record — Object-relation mapping put on rails
>
> Active Record connects business objects and database tables . . .
^^^^^^

Why does it connect "business" objects? Does this mean it wouldn't be able to connect "non-commercial" or "NGO" objects? What about artistic objects? Would activerecord be completely useless for a database containing info on my personal CD collection?

Please enlighten me as to how something so technologically (not to mention ideologically) limiting worked its way into the fundamental design of this library.

"Buisiness Objects" don't refer to licensing, but to doing or modeling
the buisiness of the application. You'll see them across all kinds of
solutions in this domain, both free and not.

···

craig duncan (duncan@nycap.rr.com) wrote:

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:

> Active Record ? Object-relation mapping put on rails
>
> Active Record connects business objects and database tables . . .
^^^^^^

Why does it connect "business" objects? Does this mean it wouldn't be
able to connect "non-commercial" or "NGO" objects? What about artistic
objects? Would activerecord be completely useless for a database
containing info on my personal CD collection?

Please enlighten me as to how something so technologically (not to
mention ideologically) limiting worked its way into the fundamental
design of this library.

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

craig duncan wrote:

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:

> Active Record — Object-relation mapping put on rails
>
> Active Record connects business objects and database tables . . .
^^^^^^

Why does it connect "business" objects? Does this mean it wouldn't be able to connect "non-commercial" or "NGO" objects? What about artistic objects? Would activerecord be completely useless for a database containing info on my personal CD collection?

The word "business" is meant to distinguish those objects from the code devoted to , say, infrastructure. In other words, they hold the code that lets your application go about its specific business, be that selling widgets, rendering nice pictures, emitting strange sounds, or cataloging your personal CD collection. The business objects typically sit on top of the framework or infrastructure objects.

Please enlighten me as to how something so technologically (not to mention ideologically) limiting worked its way into the fundamental design of this library.

It's a common term used among many "professional software developers"; i.e, people who write software for businesses. There are no doubt other ways to name chunks of code so that you can define and maintain a reasonably clean partition between the plumbing and dishwasher.

James

The business objects doesn't really have anything to do with business in
a commericial context :slight_smile:

Other terms for the same kind of objects are "domain objects" or "entity
objects". These terms are pretty much standard in OO litterature. Pick
up "Domain Driven Design" by Eric Evans to read more about the "real"
meaning of the terms.

As a related side-note, "Active Record" is a design pattern coined by
Martin Fowler (afaik anyway) that describes /how/ these business objects
are mapped to relation table data. An alternative design pattern is Data
Mapper (also coined by Mr Fowler).

HTH //Anders

···

On Sun, Oct 31, 2004 at 02:55:59AM +0900, craig duncan wrote:

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:

> Active Record ? Object-relation mapping put on rails
>
> Active Record connects business objects and database tables . . .
^^^^^^

Why does it connect "business" objects? Does this mean it wouldn't be
able to connect "non-commercial" or "NGO" objects? What about artistic
objects? Would activerecord be completely useless for a database
containing info on my personal CD collection?

Please enlighten me as to how something so technologically (not to
mention ideologically) limiting worked its way into the fundamental
design of this library.

--
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Anders Engström aengstrom@gnejs.net
. http://www.gnejs.net PGP-Key: ED010E7F
. [Your mind is like an umbrella. It doesn't work unless you open it.]

It is an odd distinction. Why is the in-memory code object, transient and fleeting, the "Business Object", while the permanent record is relegated to the invisible role of "plumbing"?

I prefer to call them BO objects, myself. Because I think they are a smell. There are points of interface that are important to the business. The place where customers buy things. The place where inventory is recorded. The interfaces used by non-programmers to monitor these things. All the stuff in between -- the BO domain -- to me, all that is just plumbing between the places where the business makes money. Like all other code smells, this one should be managed in a discrete fashion.

Cheers,

Patrick

···

On Saturday, October 30, 2004, at 03:23 PM, James Britt wrote:

craig duncan wrote:

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:
> Active Record — Object-relation mapping put on rails
>
> Active Record connects business objects and database tables . . .
^^^^^^
Why does it connect "business" objects? Does this mean it wouldn't be able to connect "non-commercial" or "NGO" objects? What about artistic objects? Would activerecord be completely useless for a database containing info on my personal CD collection?

The word "business" is meant to distinguish those objects from the code devoted to , say, infrastructure. In other words, they hold the code that lets your application go about its specific business, be that selling widgets, rendering nice pictures, emitting strange sounds, or cataloging your personal CD collection. The business objects typically sit on top of the framework or infrastructure objects.

Please enlighten me as to how something so technologically (not to mention ideologically) limiting worked its way into the fundamental design of this library.

It's a common term used among many "professional software developers"; i.e, people who write software for businesses. There are no doubt other ways to name chunks of code so that you can define and maintain a reasonably clean partition between the plumbing and dishwasher.

Patrick May wrote:

It is an odd distinction. Why is the in-memory code object, transient and fleeting, the "Business Object", while the permanent record is relegated to the invisible role of "plumbing"?

Well, in this analogy, the plumbing would be the database and the library code needed for database access. The data themselves, though, are not plumbing, and are arguably more important than any of the code, business or otherwise.

And, assuming you have your business code on disk, it shouldn't be any more transient and fleeting than any other code.

I prefer to call them BO objects, myself. Because I think they are a smell. There are points of interface that are important to the business. The place where customers buy things. The place where inventory is recorded. The interfaces used by non-programmers to monitor these things. All the stuff in between -- the BO domain -- to me, all that is just plumbing between the places where the business makes money. Like all other code smells, this one should be managed in a discrete fashion.

Well, call them what you like. As a practical matter, though, the term 'business object' is quite common, whatever one's personal views on the philosophy behind it. But I would suggest that in the common parlance it is in the business objects where money-making code resides. Well, unless you sell the plumbing.

(I'm also getting the impression that you believe that code that makes money for a business smells, or is somehow distasteful, but I may be misreading your comments.)

James

James,

(I'm also getting the impression that you believe that code that makes money for a business smells, or is somehow distasteful, but I may be misreading your comments.)

It's not that I think that code that makes money smells. I just think that the code refered to as "Business Objects" isn't really the place where money is made.

I think most of the code referred to as "Business Objects" is really plumbing. In my experience, everything about these structures is dictated by requirements coming from the edges of the system. It doesn't help me manage change if I focus on effects, rather than the causes.

What I find distasteful is when a system is defined through a set of BO objects. When you focus on the edges, the system can become a part of the process of making money.

Cheers,

Patrick

···

On Sunday, October 31, 2004, at 10:42 PM, James Britt wrote: