"Business" objects?

[craig duncan]

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]

--DrWhICOqskFTAXiy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:
=20
^^^^^^
=20
Why does it connect "business" objects? Does this mean it wouldn't be=20
able to connect "non-commercial" or "NGO" objects? What about artistic=20
objects? Would activerecord be completely useless for a database=20
containing info on my personal CD collection?
=20
Please enlighten me as to how something so technologically (not to=20
mention ideologically) limiting worked its way into the fundamental=20
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.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--DrWhICOqskFTAXiy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFBg+jlMypVHHlsnwQRAjSHAJ9aA8ILY967DqotPToiS0o9Gbty7gCeMdHE
yhkRJ6dsC4GfUzp0Z6JmF+Y=
=6Kg6
-----END PGP SIGNATURE-----

--DrWhICOqskFTAXiy--

 

[James Britt]

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

^^^^^^

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]

--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoted from ... ruby/gems/1.8/doc/activerecord-1.0.0/rdoc/index.html:
=20
^^^^^^
=20
Why does it connect "business" objects? Does this mean it wouldn't be=20
able to connect "non-commercial" or "NGO" objects? What about artistic=20
objects? Would activerecord be completely useless for a database=20
containing info on my personal CD collection?
=20
Please enlighten me as to how something so technologically (not to=20
mention ideologically) limiting worked its way into the fundamental=20
design of this library.

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

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

--=20
=2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=2E Anders Engstr=F6m (e-mail address removed)
=2E http://www.gnejs.net PGP-Key: ED010E7F
=2E [Your mind is like an umbrella. It doesn't work unless you open it.] =
=20


--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBhAjOuNLLbe0BDn8RArz6AJ9bY+YyPZWntILcPM0jaUwx8gB7jQCeIE7E
KQ9WS9QYrMT6tzGX2zk5Y5E=
=sPbS
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--

 

[Patrick May]

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.

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]

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]

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