Using BusinessListBase and BusinessBase and choosing Child or Parent

Using BusinessListBase and BusinessBase and choosing Child or Parent

Old forum URL: forums.lhotka.net/forums/t/7384.aspx


nhwilly posted on Saturday, August 01, 2009

I am writing a scorekeeping system as my first CSLA project. 

I believe I am interpreting the parent vs child decision correctly by using a general rule of thumb whereby a collection contained in a parent is a child collection if the items in it are saved only when the parent is saved.  Like saving a line item when the invoice is saved.

Am I on the right track here?

I have the following scenario:

Event
  |-->Tournaments (read only list base)
        |-->Tournament (parent)
              |-->Competitions (read only list base)
                    |-->Competition (parent)
                          |-->Rounds (read only list base)
                                |-->Round (parent)
                                      |-->Matches (read only list base)
                                            |-->Match (parent)
                                                  |-->CompetitorsScores (child list)

The reason the stereo types were chosen this way is that the competitors scores are contained within a match and match exists as a transaction that exists only to contain competitors scores.  In other words, the scores are all entered and then the match is saved.

The parent of Matches is a Round, but a Match is saved by itself and while it belongs in the context of a Round, we wouldn't save modified matches in a collection when we save a round.

Each of these objects has a few other properties, and some of those properties would be calculated based on the collections they contain (competition winning competitor, for example).

So that means that a change in a Match that is saved will ripple up to the tournament level to effectively change the winner.

So I can see it both ways.

Any suggestions (still shaking off that relational fever)?

Thanks in advance.

Bill

p.s. BTW, a tournament does not have to exist for a competition to exist.  Ditto for Event and tournament.    Those only exist for more complex situations (multiple games over multiple days with sub competitions within them).  So a competition can stand on it's own.

RockfordLhotka replied on Saturday, August 01, 2009

nhwilly:

p.s. BTW, a tournament does not have to exist for a competition to exist.  Ditto for Event and tournament.    Those only exist for more complex situations (multiple games over multiple days with sub competitions within them).  So a competition can stand on it's own.

That's the key point. These are all top-level concepts then.

Does your employer own you? No? Then Employer->Employees->Employee isn't a valid object model, because that implies ownership.

Your objects will often represent relationships between entities, not the entities themselves.

If a Competition is a thing, that's good. If a Tournament is a grouping of Competitions, that implies a relationship, but not necessarily ownership.

So Tournament->Competitions->TournamentCompetition might make more sense, where TournamentCompetition represents the fact that a Competition has been associated with the Tournament, but isn't the Competition itself.

jasonlaw replied on Monday, August 03, 2009

May I know how to reflect the ownership & relation in object model?

Thanks in advance.

RockfordLhotka replied on Saturday, August 01, 2009

I should point out that all of this is predicated on the user's expectations.

What is the usage scenario you are trying to meet here? Creating an object model in the absense of a usage scenario is a pointless exercise.

nhwilly replied on Saturday, August 01, 2009

And I thought a "useless exercise" was what I did at the gym.  :)  

I didn't want to burden you with the whole involved design; you're generous enough just to share your ideas and the framework in general.

We are a gaming center (my life after running a software company) and we often stage large group events.  Sometimes they last an evening or a day and other times span several weeks.

A one night/day affair would be a Competition.  Single game, single scoring mechanism.  Often impromptu, so no tournament and no event in sight.  Setup is quick; customers join (perhaps forming teams or solo) and are dropped into matches, they compete, scores are recorded and then presented on a large screen (hence the project name: ScoreBoard, and the interest in SilverLight).

OR - Last month we attended a fair and planned competitions for different age groups in a single game (making for different competitions in a single tournament - 1 vs 1 Guitar Hero, actually).  Furthermore, more than one game was involved (we added PGR4 racing where ranking points are scored).  Everyone would expect that to be a different tournament, hence there would be an Event object (the entire weekend at the fair for all games).  The event serves to present a collection of tournaments and their winners.

So the most prevalent use case is one where a staff member quickly creates a competition, enters the names of the competitors and assigns them into matches.  When a match completes, the staff notes the scored values for each competitor (a race might have 8, whereas Guitar Hero would have 2) and enters them in and then *saves the match*.  When the last match completes, the scoredboard determines the rankings and everyone knows who won or lost (and most importantly - how close it was :)).

So a match "owns" the scores, that's a really good metaphor that will stick for me.  Thanks for that.  And by the same reasoning, a competition *owns* a collection of matches since they don't exist outside of a competition.

The only thorn is that in working with a crowd, we often have multiple staff updating the matches at once to keep the event moving.  And while there won't be any collisions at the match level, if we have to update the competition object because it's the parent, then the likelihood of collisions goes up substantially - in fact, you could bet on it.

And now that I think about it, your suggestion of the object as a relationship fits the PTracker example.  (Whenever I start moving too fast, the relational thinking takes over and I miss the obvious connections between your example and what I'm doing.)

But to the original question, a Tournament would then "own" the TournamentCompetitions collection but not the competitions so the collection would be a child and a competition would still be a parent.

Right?

Copyright (c) Marimer LLC