Lessons learned since the first time around (XNA and Model-View)
I've been struggling with the next few posts since if I had it to do again, I'd probably do it differently. There has been a lot of buzz about Model-View-Controller (MVC) patterns. Model-View-ViewModel (M-V-VM) is also gaining ground, and is a recommended pattern for WPF and Silverlight applications. Now I'm not a big Test Driven Development guy, but there are definitely some benefits to these Model-View patterns. They may take a bit longer up front and cause some more design work, but your code will generally be more reusable and you'll have a better separation of display logic and back end logic.
For writing games, should I care? Isn't game development more of a GED (Git 'er done) design pattern? It depends. For me personally, porting my Dr. Popper game from XNA to Silverlight was a pretty painful process and pretty much a complete rewrite. Why? Because the way things are displayed on the screen is completely different in Silverlight. In XNA, you draw everything, every frame. In Silverlight, you place something on the screen and forget it until you need to move it or remove it.
By implementing one of the design patterns above, you can separate the drawing logic from the rest of the game logic and make it much easier to run your game on multiple platforms.
On the other hand, using these concepts can be a more advanced development style, and introducing those concepts at this part of the tutorial series is probably a mistake. So what I've decided is to continue on the original path of the tutorials, and after covering some of the basics of classes, objects, and collections, I'll show how we can refactor the code to be more Model-View based.
Model-View designs, like any other technique, are just another tool you can use to create your applications, and in my opinion there are cases where it makes sense and others where it doesn't, and we probably will implement the parts of it that make sense for this, but I won't claim that it's 100% conforming to the doctrine.