Conceptual question about MVC

[trisweb]

Ok, this is a pretty silly argument, but my friend and I decided to take it to a forum instead of arguing the point without any resolution.

So we have an MVC-based application in Flex, and there's a model which is a fairly deep object graph. We use properties and property chains to access parts of the model in our view (such as foo.bar.baz[n].property).

Our argument is essentially on a point of wording. I will attempt to give fair explanation to both sides...

I say that the access of the model 'foo.bar.baz[n].property' or even anything as simple as 'foo.property' is part of the view. I say this because by definition, the model is simply a graph of connected objects which does not care which parts of it are in use at any given time. Thus by definition a "usage of the model" cannot be called "the model" because a usage implies some state.

My friend says that this part of the model is Model by definition, because it's a part of the model, regardless of how that part is accessed, and the model is still model regardless of which part of it you're looking at. So he says 'foo.bar.baz[n].property' is called 'model' through and through.

My contention is that any context or state of the model cannot be "the model" by definition. The model is this pure set of objects which is completely separate from its usage by the controller or view. So I have trouble calling any property access a part of the "model." I see his point of view in that by simple categorization, an access of the model might as well be called model itself.

What do you think? Is 'foo.bar.baz[n].property' Model or View?

[MichaelxxOA]

Can you specify what is being accessed and for what purpose?

And out of curiosity, what happens if you apply the law of demeter (http://c2.com/cgi/wiki?LawOfDemeter)?

[yell0wdart]

Yea, some context would be fantastic.

[trisweb]

Perfect example would be a simple custom label component, on a page for a Product item, which displays some label field down a chain of properties.

Example: <FieldDisplayLabel dataSource="{product}" field="{['property', 'chain', 'goes', 'here', 'labelField']}"/>

I realize it's complicated; it's a deep graph of objects we're dealing with and this is the simplest way to organize properties within various components and diverse references.

As far as the Law of Demeter is concerned, I'm not going to attempt to predict which paths the view might ever want to access such that only Product accesses them through single methods - that would be silly and inflexible and would result in more complexity than what it's trying to manage. The evaluation and binding of the property chain is what we control generically, and this works quite well.

We've essentially come to a consensus in the meantime. Of course Product and its properties are part of the model, and of course referencing them and deciding what to reference is part of the view. This is where the view intersects the model, as is any property access. Makes perfect sense, and the semantics of what's on which side of that abstraction are not worth arguing about.