MVVM and Custom controls RRS feed

  • Question

  • As kind of a followup to a previous thread I started:

    I'm trying to get my little brain around where things should be going architecturally.  The easiest example of what I am trying to do would be the famous MineSweeper game on every windows machine.  I need to let the user decide something, like how big the mine field is, and then draw the grid with little graphics elements in each cell.  In my specific case I would need row and column headers as well.  When the user clicks on a particular cell, an event is sent, things can change, etc.

    So is this considered a custom control?  And does it make sense to try to follow an MVVM pattern with such a control?  I am thinking that this kind of thing is really all view- with minimal data being required from a ViewModel, or model.  In the mine sweeper case, maybe the viewmodel would determine where the mines are and then pass this to the view for drawing?

    And then the codebehind would be filled with lots of drawing code, right?  

    I guess I am just happy with the MVVM pattern, but for any real custom graphics it seems it is not fitting very well- and that perhaps I need an app that uses MVVM where it can, and if custom stuff is needed it just does it in the codebehind rather than trying to force it to fit a pattern that is not suitable.

    Any thoughts, or examples that might help me out?
    Tuesday, November 3, 2009 6:08 PM


  • Saxisa,

    I recommend reading Anatomy of an MVVM Application.  The diagram at the end, especially, really shows how to think about controls in terms of MVVM - although read the article first without skipping ahead (it'll make more sense).

    In your case, say you were making something like Minesweeper -

    In this case, I'd probably make some class that holds the information for a "Cell" (ie: is it mined, etc).  These would sit inside of a Minefield class of some form, which would handle the triggering case - ie: when this cell is hit, does it explode?  Does it change the neighbor cells? etc.

    This is really all part of the Model.  The actual state of the application, the raw data, is all handled this way.  It has nothing to do with HOW you're interacting with it.  You could be using a console program (think battleship - ie: tell it row 5, column 3, and it tells you what happens, all with a text api), a website, your GUI application, etc - as far as the model's concerned, it's just data that is being changed by something externally.

    The View, on the other hand, needs to display this as a grid, and have a way for the user to interact with the GUI.  This could probably be done pretty easily using some type of GridView class, with headers, used to display the individual Cell elements as a picture (DataTriggers could be used to swap between the 3 pictures required, etc).

    The ViewModel would just provide the "glue" to tie the two pieces together.  It probably would expose some a command for "Mine Clicked", so the individual cells could propogate a mouse click on the cell (which could be a button) to the ViewModel, which would in turn, fire the change cell state method in the model.
    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by Linda Liu Monday, November 9, 2009 2:46 AM
    Tuesday, November 3, 2009 7:06 PM