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.

  • 3
    MVC is mostly a user interface paradigm. You seem to be describing a ViewModel. Jun 19, 2012 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, 2012 at 2:04
  • 1
    We do use ViewModels in MVC as well. geekswithblogs.net/michelotti/archive/2009/10/25/… Jun 24, 2012 at 4:25

2 Answers 2


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.

  • 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, 2012 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!

  • 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, 2012 at 2:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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