5

I'm developing mobile applications for Windows Phone 7. This application calls some web services and occasionally sends responses out via web services. I recently started looking into MVVM and noticed that, although it is suggested when developing applications in WP7, alot of developers say only to use it if its necessary. Along with that they said that if the application is "small" enough or "simple" enough then it probably isn't worth the time. Hence my question.

When should we use MVVM? Is it possible to build larger scale applications without it?

|improve this question
  • Do pieces of your app talk to other pieces often? If so, a framework or IOC container could be helpful. – Jon Onstott May 4 '11 at 22:57
  • @Jon I pass data from page to page. But other than that there really isn't communication between the different components of my app. – Edward May 4 '11 at 23:22
5

If your application uses WPF or Silverlight, use MVVM.

It doesn't matter how simple your application is. It is a very easy pattern to learn and it makes future maintenance/updates extremely easy. It also makes it so new developers, or even someone looking at the code a few years from now can understand what is going on quickly.

|improve this answer
  • 1
    +1 I agree, except that I would not always say it makes it easier for new devs(as in junior devs). We have a few people that don't quite "get" MVVM yet. It makes a very large project we have a bit confusing, because we have a beautiful MVVM structure, but a few random ugly methods in the code-behind that tend to get lost. Still though, MVVM works great and is better than nothing. Its like test coverage; get as much as you can with what you have. – Morgan Herlocker May 5 '11 at 15:19
  • @ProfPlum I was thinking it would be easier for jr devs since they know if there is a change to the data structure, go to the model. To the functionality, go to the ViewModel. To the UI, go to the View. I used to get so lost trying to figure out where values were getting set, what code was getting executed, etc. It used to be that stuff was spread all over the place. Sometimes in the classes, sometimes the code behind, sometimes a static method, etc. Perhaps it is just that I didn't work with standard WinForms (or worked with bad Winforms apps) a lot before I picked up MVVM – Rachel May 5 '11 at 15:47
  • @Rachel see this is what I heard. The thing is I've tried to learn this but found a lack of resources for implementing this in WP7 applications. What made it a little more confusing on top of it was the fact that the examples I studied each implemented it in a different way. What's your suggestion on how I can get started? – Edward May 5 '11 at 16:56
  • 2
    As for where to start, I don't know. I started with msdn.microsoft.com/en-us/magazine/dd419663.aspx, but I'm sure there are simpler examples out there. Perhaps I'll write one up... I honestly haven't seen any – Rachel May 5 '11 at 17:11
  • 1
    @loyalpenguin You can try mvvmbasics.wordpress.com if you want.... I've never written about anything so don't know if its any good or not. But it's an attempt to give a starting point into MVVM. – Rachel May 9 '11 at 19:42
3

It's always possible to build larger scale applications without following a design pattern. However, following a pattern generally allows for greater decoupling of subsystems and therefore, increasing the ease of scaling your system.

Personally, I always follow a pattern when developing my applications, whether it's MVVM, MVC, HMVC or others. Having said that, I'll only adopt a pattern if it makes sense for the project. You don't want to blindly follow a design pattern just because someone told you it's a good idea :) You never really know how complex your applications are going to become over time and releases. So in my mind, it's always better to take the time to build a solid foundation with a design that fits the system I'm building (if there is one) rather than build a custom framework that may not scale well at the end of the day, and then end up refactoring code that I had previously written to fit into one of those designs.

|improve this answer
  • 1
    +1 for "You dont' want to blindly follow a design pattern just because someone told you it's a good idea". I tried implementing it because they told us to and found that I was creating twice as many files along with making the application way more complex than it needed to be. I guess theres always a balance. – Edward May 4 '11 at 23:24
1

I recently (last year or so) did use MVVM on a project that absolutely did not need it just to learn it. Today I'm very glad that I did.

The application isn't extremely complex but my experience now is that I can add new functionality very easily and naturally into it even if I didn't touch the code for some time, much more than in my other programs. MVVM is also very widespread used so you use a design pattern for which you get much help if you have questions. You are not alone with it so to say. ;)

Further I did not add any testing since it was just a pet project so far and today where it is more used than I thought it would be I can easily add testing much more comfortably than I ever could before since ViewModels are just great for testing.

In one of your comments you mentioned an increase in boilerplate code which in my experience mostly comes from the fact that many people publish their properties from their Models only into their ViewModels, duplicating much code in the process. I usually implement INotifyPropertyChanged in my Models to circumvent that. Some see that as bad practice but that's the beauty of it, the design pattern is still fresh and talked about (see Sasha Barbers opinion to this at at codeproject under "Developing Models Using Cinch").

So you can absolutely ignore it for sure and write great software still but I would recommend carefully weighing the advantages you might miss before doing so.

|improve this answer
0

MVVM is generally not a requirement, but what is the alternative? No one likes dealing with Spaghetti Code, and frameworks like MVVM light and PRISM make it pretty easy to learn. I actually had to change out a Model and modify some logic in a ViewModel this morning that I wrote about 9 months ago. I didn't have to touch the UI, and could seperate the problem into managable pieces. It was never that complex of a project, but I think its actually more convenient to have loose coupling. The only real time cost is in the learning phase. It seems hard to wrap your head around though, and then one day poof, you'll know it and never want to go back on even the most trivial projects.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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