Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Model/View separation again  (Read 2583 times)
shanestevens
Jr. Member
**
Posts: 17


View Profile Email
« on: October 09, 2011, 03:41:53 »

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

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 09, 2011, 10:45:58 »

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>
Logged
shanestevens
Jr. Member
**
Posts: 17


View Profile Email
« Reply #2 on: October 09, 2011, 05:50:38 »

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
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 10, 2011, 06:44:22 »

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>
Logged
Pages: [1]
Print