Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm working on an application in which I'm looking to employ the MVC pattern, but I've come up against a design decision point I could use some help with.

My application is going to deal with the design of state-machines. Currently the MVC model holds information about the machine's states, inputs, outputs, etc. The view is going to show a diagram for the machine, graphically allowing the user to add new states, establish transitions, and put the states in a pleasing arrangement, among other things.

I would like to store part of the diagram's state (e.g. the x and y state positions) when the machine information is stored for later retrieval, and am wondering how best to go about structuring the model(s?) for this.

It seems like this UI information is more closely related to the view than to the state-machine model, so I was thinking that a secondary model might be in order, but I am reluctant to pursue this route because of the added complexity. Adding this information to the current model doesn't seem the right way to go about it either.

This is the my first time using the MVC pattern so I'm still figuring things out. Any input would be appreciated.

share|improve this question
3  
MVC is mostly a user interface paradigm. You seem to be describing a ViewModel. –  Robert Harvey Jun 19 '12 at 22:59
    
Hmm, MVVM does look to be somewhat along the lines of what I was looking for, but straight MVVM won't do. Handy pattern to know about though, thanks! –  paul Jun 24 '12 at 2:04
1  
We do use ViewModels in MVC as well. geekswithblogs.net/michelotti/archive/2009/10/25/… –  Robert Harvey Jun 24 '12 at 4:25
    
That was a nice overview, thanks for the link! –  paul Jul 18 '12 at 0:27

2 Answers 2

up vote 6 down vote accepted

You have two models

one model is the state-machine: inputs, outputs, states, transitions, et al

the other model is the presentation/rendering of a state-machine: icons, x/y/z coordinates, fonts, scales, etc.

share|improve this answer
1  
You're absolutely right. While putting the two models together in one when they're small, as TomasAlabes suggested, was appealing, I do have two separate models and they should be treated separately -- this will be especially important if the diagram model grows, and it looks like it might. Gotta do things right the first time. –  paul Jul 18 '12 at 0:26

You clearly have 2 options:

If the UI info is just a few things, the best approach is to unite both "models" and avoid unncessesary complexity.

If the UI info is large, create a UI Model should be the correct choice.

It's understandable your doubt in this matter, is a common one. That UI info needs to persisted, so you need some kind of "model" representing the view info to load when the editor loads. Programmatically you could relate both models by an id.

Hope it helps!

share|improve this answer
    
I had been thinking of using an ID, but was having a tough time figuring out how best to do so. Thankfully Clojure has transactional memory, so it'll work out fine :) –  paul Jun 24 '12 at 2:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.