[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

"Business" objects?

craig duncan

10/30/2004 5:56:00 PM

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.
6 Answers

Eric Hodel

10/30/2004 7:18:00 PM

0

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.

"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.

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

James Britt

10/30/2004 7:24:00 PM

0

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

Anders Engström

10/30/2004 9:36:00 PM

0

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.

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

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

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

Patrick May

11/1/2004 3:06:00 AM

0


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.

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

James Britt

11/1/2004 3:43:00 AM

0

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

Patrick May

11/1/2004 5:38:00 AM

0

James,

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

> (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