Re: Best practices in a thin-controller application

Hi Bryce, Daniel et al.

Well, it seems there is a confusion about what a "valid" object is.

> IMHO, many architectural decisions like this are subjective, 
> and as such, there is no universally accepted "right" way to do it.

The only *subjective* thing is how you define "validity".
In this discussion I would prefer "complete" instead of valid.
With "complete" I want to express that an object is build of that "things"
that make it such an object, its *identity*. 
And valid menas that it exists AND has some state that determines validity.

If you consider an object to be generated only in a (minimal) complete state,
than the form of this is your decision and freedom. 
But you may not bruise this rule.
If an object isn't of a form that reflects its clear identity , 
then it is simply not existent.
Another thing would be the creation of an complete object that has a state
that isn't valid. But to/for/from what? The context sets the validity.

An small example:
Let's have a class HomoSapiens. You want to get a "complete" HomoSapiens object
in return and your definition for that one is "It has a brain, a heart and a 
unique DNA". These are the minimal, basic elemnts of an object HomoSapiens.
So if you can't assure one of these and therefore can't generate a complete 
HomoSapiens, you simply have none, it could not be created.

"Valid" IMHO is always some kind of rule in a context.
But if something is valid can only be determined if it exists.

You cannot have a half-pregnant mother...
;-)