Scott,
Don't know if i'm "correct" or not, but i don't think you need
composition here. Here's my reasoning ...
If
you needed the ability to edit the article and a variable number
of comments at the same time, in one page view, then i would say that this
use case would support a model like the one your are proposing. But i assume
(and hope) you won't be setting up the app that way. I assume you'd open
the article and each comment separately for editing -- even from a
usability perspective this makes sense. Imagine a blog article that had 20
comments attached to the article and when you went to edit something, 21
stacked forms opened, populated with data for you to alter at your whim and
submit all at once. Horrible from a user interface perspective.
So
in my opinion, you need a simple gateway for your comments that you pass the
articleID into and that will suffice. I'm wary of using "has-a" and "is-a" as
priniciple guides into the object modeling wilderness, advisors, yes, but not
guides. A blog has articles, articles have comments and users that created
them, an article has-a datetime stamp, has text ... geez, articles and
comments both have text and articles have comments ... how do i model THAT?
One can very easily get confused.
In
my app here, i have comments attached to pages, content blocks and the
application as a whole, and although the application has comments, pages have
comments, and content blocks have comments (and the app has pages and pages have
content blocks), it's not modeled in the way that "has-a" implies, because it's
not needed in the way the application works. Just to say, I have an adminManager
with a few simple boolean methods, IsPageComment and IsContentBlockComment that
call the necessary gateways and return a true or false. An icon indicates to the
user if there is a comment attached to the page or content block, and clicking
on the icon opens the list of comments view, handled very nicely by a
CommentGateway, and a form for adding a comment, handled by Comment and
CommentDAO if submitted.
To
me, object relationships shouldn't just be theoretical, they need to be working
relationships, otherwise you can wind up building a model that you won't make
any use of. And I don't know about you, but i get really lost in a roomful
of objects that are just standing around, socializing for the hell of it.
I try get them working on their own, and if they can't do their job by
themselves, i figure out who can help them most efficiently - forming lean
working relationships as needed. Anyone left over gets tossed into a bin of
discarded objects i keep here next to my desk.
:)
Nando
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, January 11, 2005 8:31 AM
To: [email protected]
Subject: [CFCDev] Newbie approach to Composite Entity pattern.Hi,I've got a concept i need to bounce off others, its similiar in its approach to say "Articles" has many "Comments" (ie Article has-a comment(s)).In my Approach (using the above basic example) i would create:ArticleBO (Composite Entity)- commentBO (Dependent Object1)- commentBO (Dependent Object2)etc..Is it save to say that the ArticleBO has methods like:- setTitle(string)- setBody(string)- setPubDate(date)- addComment(commentBO)- removeComment(commentBO)- findCommentByID(string)I guess what i'm trying to do is combine the efforts of a "Bean" and "Facade" into one object that my controller/container accesses. So in the event i add a comment to my article, i invoke addComment(), pass in a collection of arguments (or object) and it stores that information within itself.I then pass that ArticleBO to my DAO, which stores all the Article "information" into say "Articles Table" and comments into "Comments" table or however i wish to implement storage (ie could serialize the entire bean to a wddx packet or something)Is this a typical approach to objects that have many dependent objects. I read that "Composite Entity Bean" works like this (Or I may loose this in translation - probably the case).Regards,
--------------------------------------------------
Scott Barnes
System Development Engineer
Goro Nickel Project
Level 8, 201 Charlotte Street
Brisbane QLD 4000
Email: [EMAIL PROTECTED]
