Re: Best practices in a thin-controller application

Thanks for your comments...I feel like I'm getting closer to
understanding the concept.  Please see my replies below...

On Fri, Jul 18, 2008 at 7:03 PM, Nino Martincevic 
<don-+TOG+kmQGiFBDgjK7y7TUQ@xxxxxxxxxxxxxxxx> wrote:
> Are you sure both Trip and Destination are both equally-weighted
> objects of the domain?
> May there be a trip without destination?
> And does every destination has a trip?

The way I've envisioned it, every Trip has to have at least one
Destination, and every Destination has to be associated with a Trip.
In the real world, a trip without a destination is just staying at
home, and a location doesn't become a "destination" until somebody
takes a trip there :)  At least that's how I've mapped it out in my
head.

> What do you mean by "root" of domain?
> Tables and domain models aren't the same things.
> A domain model exists without a table with no problems, persistance is only
> a technical drawback of software or the need for storing something because
> we have no chance to let the object live forever.

You're right, "root" probably isn't the right word.  Here's the
problem: occasionally my users will want to see a list of all the
Trips that the system is currently keeping track of.  The controller
shouldn't know how to get this list, since that's business logic.  But
a single Trip instance really shouldn't know how either, since it's
only supposed to be aware of itself.  This means we need a separate
domain-related object whose job it is to manage all the Trips
together.

So, when I said "root," what I really meant was that high-level domain
object...maybe I should call it the Travel_Agent (!).

> Better express your needs it in pure speech:
> "Show me a list of all Trips to (from?) France"
>
> Who answers this question?

If my comments above are correct, the Travel_Agent answers this
question, because the travel agent is the one who keeps track of the
Trips.

> Think of a collection or list as something like a list on paper.
> It's only a list of things (objects) that are not "living", they have no
> state, they are only written on something or said by someone.

So maybe when the user asks the Travel_Agent a question, the
Travel_Agent returns a Travel_TripList (or maybe just an array of
Trips) in response.  That corresponds easily enough to the paper list.
 I don't know that it needs to be an object; an array of Trips would
probably suffice.

> Errors should be there where they make sense.
> And entities (domain objects) should never be created (be returned) if their
> creation has failed but only in a consitent state.
> Only if the creation has a state other than "valid" and it is intended to
> return such an inconsistent object.

OK...so if the object can't be constructed valid, it shouldn't be
constructed at all.  As far as I know, the only way to do that in PHP
is with exceptions, as per my first example.  And then I can use
multiple exception subclasses to handle the various reasons why the
construction failed, which the controller can use to provide the user
with appropriate error messages.

Thanks for your help; I feel like I'm a lot closer to understanding
what the Model is supposed to be.  Does anyone have any further
suggestions?

Thanks!
Adam Jensen