Model/View separation again

[shanestevens]

I have a WorldProxy.  The WorldProxy is responsible for managing WorldObjects, that includes their spatial structure, their lifetimes, their current state, and is also responsible for updating all of them at a set interval.  This all ticks, excuse the pun, along nicely.

When it comes to rendering the objects, I have a WorldMediator which uses the database held in the WorldProxy.  It takes care of visibility, a camera, all the stuff that's render related.

Historically, all of my WorldObjects would have a tick() and a render().  Currently they have a tick(), which is what makes everything work, however, I can't have a class that has one foot in the Model layer, and the other in the View layer.

The trouble is, the WorldObject really should render itself, because it knows about its internal state, which assets belong to it, etc.  If I had a separate class to render the WorldObject, it would be an outsider looking in, breaking encapsulation.

The only other way I can think of doing this, the PureMVC way, is to have the WorldProxy do nothing except hold the state data, then have the spatial structure held in the WorldMediator.  This feels wrong to me though, given the role of the Model in my case is to be a database.

How is this dual life usually handled in PureMVC?

- Shane

[puremvc]

View components are generally in charge of maintaining their own state. The StateMachine Utility is often used to control overall application state, and the Mediators merely translate changes in application state to changes in view state by responding to app state changes and setting some data or calling some method on their view components. If you don't want to use a formal state machine, the same is true of any notifications flying around the app.

While Proxies in the Model tier may need to hold some data related to the application's state (such as the currently loaded invoice in a billing system), they don't do so in a way that makes them in any way aware of the View and Controller apparatus. A good way to enforce this is to break the Model classes off into their own library project that knows nothing about the application it's used in.

-=Cliff>

[shanestevens]

I guess it's the term "View" that keeps getting to me.

I've often seen code that sits in a View Mediator, which has nothing to do with view/rendering.  For instance, sound management, application state, etc.

I'll split my objects in two.

- Shane

[puremvc]

Mediators are not for code-behind. A Mediator should really just facilitate communication between a view component and the rest of the application. The view component should encapsulate its own behaviors and state.

-=Cliff>