Home » Architecture » The MVVM Pattern Is Highly Overrated

The MVVM Pattern Is Highly Overrated

102 commentsWritten on July 21st, 2010 by Davy Brion
Categories: Architecture, Code Quality, Silverlight

Update: check out my MVP In Silverlight/WPF series which discusses the MVP approach as an alternative to MVVM

If you're doing Silverlight or WPF, you've no doubt come across the MVVM (Model-View-ViewModel) pattern. It seems to be the most popular client-side architecture pattern used among Silverlight/WPF developers. I find the pattern to be highly overrated, and actually have some big issues with the whole thing.

First, let's briefly cover what MVVM is about for those of you who don't know yet. MVVM virtually eliminates all of the code that would typically be placed in the code-behind file of your View (a user control, a screen, whatever) by putting all of that logic in the ViewModel. The ViewModel itself is never tightly coupled to the View. If it does have a reference to it, it's typically through an interface that the View implements instead of a reference of the actual type of the View. This increases, or better yet, introduces testability to a large part of your UI code that you normally wouldn't be able to cover with unit tests if you'd go with the traditional "put it all in the code-behind"-approach.

The ViewModel typically contains properties for the data that is to be shown in the View, and also raises notification events when the data in those properties changes. The View uses the powerful data-binding capabilities of Silverlight/WPF to bind the properties of the ViewModel to other user controls that the View is composed of. User-events that are captured by the View are sent to the ViewModel through Commands. Typically, these commands execute a method in the ViewModel which contains some kind of logic... usually to either send the updated data in the ViewModel's properties to the Model (usually a Service Layer in Silverlight, in WPF it could be either a true Domain Model or also a Service Layer), to perform some business logic in the Model, or to retrieve data from the Model so it can be placed in the ViewModel's properties so the View can bind to it.

That is, in a nutshell, how the MVVM pattern works. So why do i have issues with this? You can develop and test most of the application's logic without being dependent on a physical View and that is typically a Good Thing, no? It sure is! However, my problem with this approach is that too many responsibilities are concentrated within the ViewModel. Its main responsibilities are to facilitate databinding and to interact with the Model. And that, in my opinion, isn't very clean. In some ways, you could actually think of the ViewModel as a glorified code-behind, with the only difference being that it's not tightly coupled to the (physical) View.

In most (if not all) MVVM implementations, a ViewModel has many possible reasons to be changed. It might need to be changed because of different data-binding requirements. Then again, it might also require changes when a part of the Model is modified. Now, i'm sure many of you can agree with me when i say that two of the most important principles in software development are Seperation of Concerns (SoC) and the Single Responsibility Principle (SRP). Obviously, the ViewModel doesn't fare well when it comes to both of these principles.

Lets forget about MVVM for a second and focus on the concerns and responsibilities that a user control can have... say, a user control that shows customer information and allows the user to edit that data so it can be persisted:

visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
communication/interaction with the Model
making data (from the Model) available so it can be displayed
outputting data in the correct user controls (for instance: various textboxes)
(simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

Without MVVM, all of these would be taken care of in the View. Obviously, not a good idea right? After all, if it were a good idea, we'd never have had a reason to start using MVVM in the first place.

Now, with MVVM, a lot of people would divide these concerns and responsibilities like this:

View:

visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
outputting data in the correct user controls (for instance: various textboxes)
(simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

ViewModel:

communication/interaction with the Model
making data (from the Model) available so it can be displayed

In this case, the View still has 3 responsibilities which is still too much according to 'the guidelines', but it's not that big of a deal (though plenty of people would argue that the simple validation would be better placed in the ViewModel). You're highly unlikely to actually want to write automated tests for pure visualization anyway and the SRP is not something that you absolutely need to follow to the extreme in every single place. For the View, this is really not a problem and very much acceptable.

The ViewModel however has 2 important responsibilities in this case, and i'd argue that these 2 things should not be done in the same place. Making data available is done through data-binding. To do this, you need a set of properties and you need to raise the necessary events. In most cases, raising those events is very straightforward, but in more complex controls you might need a bit of additional logic to determine which event should be raised at what point. The other important responsibility is the communication/interaction with the Model. In most Silverlight applications, the Model will be a Service Layer. To communicate with this Service Layer, you need Service Proxies. That means that your ViewModel is essentially responsible for communicating with the Service Layer, dealing with business exceptions that might be thrown by some service calls, and dealing with technical exceptions that can occur simply because of network-related problems. Group all of those together and i don't think i'm going out on a limb here by saying that that is a lot of logic to put in one class, no?

(Sidenote: what i don't really understand is that many people who vigorously advocate adherence to SRP and SoC in their domain and business code don't seem to hold their UI code to the same standards. I do.)

At work, we do a lot of Silverlight development. We typically have around 5 Silverlight projects in active development at the same time. And it's been that way for over a year now. That equals a lot of Silverlight code that we've written and experience and knowledge that we've built up. And we haven't used MVVM for any of it. All this time, we've been using the MVP pattern (Supervising Controller variant) with a slight twist. That twist being a slimmed down version of a Presentation Model. Our Presentation Model's sole responsibility is to facilitate data-binding, and in some cases, a touch of validation is added as well.

If we go back to our previous example of the customer screen, the responsibilities and concerns would be divided like this in our MVP-PMlight approach:

View:

visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
outputting data in the correct user controls (for instance: various textboxes)
(simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

Presenter:

communication/interaction with the Model based on the contents of the Presentation Model

Presentation Model:

making data (from the Model) available so it can be displayed

Which leads to classes which are more focused on their task instead of trying to focus on too many things at the same time. In my opinion, this approach is much better/cleaner than MVVM. Not only is there a noticeable benefit in code quality (classes are more focused), there is also increased potential to reuse our 'light Presentation Models' in multiple controls. Testability is increased over MVVM as well since it's always easier to test classes which are focused versus testing classes which have too many responsibilities. All in all, a couple of important benefits and we still haven't thought of a real drawback compared to MVVM.

« Which Language Do You Code In?Is That How You Talk To People? »

This entry was posted on Wednesday, July 21st, 2010 at 15:23 and is filed under Architecture, Code Quality, Silverlight. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

http://davybrion.com Davy Brion
1) do you not use the INotifyPropertyChanged interface and the PropertyChanged event to improve your databinding? Is that not something that you have to do? If you have ‘calculated properties’, are you not responsible for manually raising the PropertyChanged events correctly? That is what i mean with ‘facilitate databinding’
2) you really don’t get it, do you?
3) once again, interaction with the model, including dealing with exceptions from the model do not belong in the ViewModel and are a much better fit for a Presenter IMO. What exactly do you not understand about that?
4) why can’t we go further with the decoupling? why must everything be concentrated in the ViewModel… because it’s already ‘testable enough’? that would be a poor reason
5) before you can make the data available, you have to retrieve it from the model. The model is quite often a service, which you need to access through a proxy. In my approach, the Presenter interacts with the model (retrieves the data) and passes it to a BindingModel (what’s referred to as a ‘light PresentationModel’ in the post, but i’ve renamed it to avoid confusion). That BindingModel in turn exposes the data to the View through properties. The View binds to those properties and is notified of changes to those properties when the BindingModel raises PropertyChanged events. That is what the post says.
6)and that is exactly what i consider to be wrong. Of course you can disagree with me, but that doesn’t mean i have to agree with you. You can write your code in your way, and i can have my opinion on that. As i can write my code in my way, and you can have your opinion on that.
“To claim that the MVVM pattern is \better\ than the MVC pattern would be idiotic. That’s like saying philips-head screwdrivers are better than wrenches. The MVVM pattern has it’s limitations, and I frequently get frustrated those who look at as if it were a religious institution where code-behind is the cardinal sin. But your objections to it are pretty confused.”
Well, my objections to the MVVM pattern revolve around the fact that everything that isn’t pure View logic is most often put in the ViewModel. Like i said, it’s essentially a glorified code-behind where anything goes, _except_ for View logic. You just said yourself that that is exactly what you do.
JustTalk
Sorry, but you’re just talking.
Where’s the code ?
I mean you seem to have all the time in the world to just say things on your blog , but no time to put together a simple sample up.
I seriously doubt you understand what you talk about.
http://davybrion.com Davy Brion
@JustTalk
i’m sorry, but i can’t just copy/paste a sample from some of our projects because then everybody will be complaining that there’s no downloadable version (been there, done that, don’t see the point in doing that again)
so yeah, i’m working on a sample which shows a couple of things, and naturally, i have to do this in my own time. Instead of just providing a sample, i want to write a couple of blog posts about it because you simply can’t do right in these situations… (or didn’t you even go through the comments to read up on the status of that? talk about all talk and no effort…) People will either complain that there’s not enough code or that there’s too much code and not enough context provided through some posts.
so yeah, i’m truly very sorry that i have to disappoint you that i haven’t spent every single spare minute i had on this so i could put this online as fast as humanly possible for you to read it, not get it, and still complain about it
nobody’s forcing you to be here, nobody’s forcing you to read this, nobody is forcing you to believe anything i’m saying, and most importantly: nobody’s forcing me to spend more time on people like you than i’m prepared to do
i’m still working on the sample as well as the blog posts, and you’ll see them when they’re _done_
until then, i’m pretty sure you’ll have plenty of other things to keep you occupied
JustTalk
@Davy Brion
“(or didn’t you even go through the comments to read up on the status of that? talk about all talk and no effort…)”
“…for you to read it, not get it, and still complain about it”
“nobody’s forcing you to be here, nobody’s forcing you to read this, nobody is forcing you to believe anything i’m saying, and most importantly: nobody’s forcing me to spend more time on people like you than i’m prepared to do”
Man! what a character ! Thank God there were some sane bits in the reply.
I’ll just say this.
When you make a public statement , you better have some code ready to prove it.
Pingback: Hey, It Is MY Personal Time After All | The Inquisitive Coder – Davy Brion's Blog
JeroenH
@JustTalk
> “When you make a public statement , you better have some code ready to prove it.”
It’s Davy’s blog. He has the right to write whatever he wants, whenever he wants. If you disagree with what he says, where’s you’re blog post with sample code to prove he’s wrong?
@Davy I think most of the readers really appreciate guys like you taking the time to blog about stuff that should be of interest to all of us. So don’t let comments like this get too you too much!
http://twitter.com/jrowett JonR
it’s obnoxious comments like those which give anonymous, socially impaired blog commenters a bad name
Dilip
You should just ignore freaks like @JustTalk — and its not irony that he has aliased himself as “JustTalk” — that is what he is probably good at. I loved your post and I appreciate the fact you spent quite a bit of time explaining your viewpoints on the MVVM pattern considering its being used like religion in a project I am currently working on. Keep blogging and forget these trolls…
Pingback: MVP In Silverlight/WPF Series | The Inquisitive Coder – Davy Brion's Blog
Mauricio
There is a name for guys like @JustTalk: TROLL.
http://www.digitaldias.com Pedro G. Dias
The code samples that I posted here were written off the top of my head (I later completed that app, btw, nice little cool thing).
It shouldn’t take you more than a few minutes to get your point through with some sample code.
http://davybrion.com Davy Brion
@Pedro
“It shouldn’t take you more than a few minutes to get your point through with some sample code.”
that goes both ways… i’d actually think it wouldn’t take more than a few minutes of actually reading what i’m saying to get it
‘some sample code’ might be enough for some people, it won’t be for others. ‘some sample code’ is also often not representative enough of the actual problem you’re trying to discuss.
hence: the MVP series
http://www.digitaldias.com Pedro G. Dias
That is just borderling on arrogance Davy.
I’ve made it pretty clear how I percieve the pattern, even posted some samples to highlight some points.
I fail to see how hard this can be from your side, instead of attacking me with meaningless rethoric. If you are actually interested in learning how to become a better developer, then I advise you to keep your tone a wee bit more humble. Arrogance will just get you ignored.
http://davybrion.com Davy Brion
@Pedro
sorry, but if my reply was arrogant, then why wouldn’t this one be:
“It shouldn’t take you more than a few minutes to get your point through with some sample code.”
i’ve clearly stated my reasons why i didn’t want to post some quick small sample code, and if you have a problem with that then that’s your problem and not mine.
later today you will be able to download the entire sample project so you can look at it, play with it, or do whatever else you want it
“If you are actually interested in learning how to become a better developer, then I advise you to keep your tone a wee bit more humble.”
i’ve demonstrated my willingness to learn from the best in this field on this blog for well over 3 years now… you’re obviously free to consider my attitude as arrogant (though i’d argue that true arrogance would’ve prevented me from spending time on the MVP series in the first place), but i fail to see how that is relevant to wanting to improve as a developer
“Arrogance will just get you ignored.”
as will unwillingness to spend more than a few minutes on something
http://www.caliburnproject.org Rob Eisenberg
What you’ve done is describe “MVVM Done Poorly” and used that as a reason to say that MVVM is not a valid UI architectural choice. No one who is experienced with the pattern would mix the concerns you discussed together unless the UI they were modeling was extremely simple. Developers make the same mistake with MVP. It’s not a problem with the pattern, but a problem with a particular developer’s approach to implementing the pattern. Let’s remember that patterns and implementations are different. Let’s also remember that there are advantages and disadvantages to every pattern and those largely depend upon the context in which they exist. Some scenarios are more easily solved with MVC, others with MVP and still other with MVVM or just a PM. There are lots of variations and combinations of these patterns. As an architect or engineer of the UI, you have to choose the best solution to the problem at hand. In WPF/Silverlight, many times it will be MVVM, but not all. On almost every project I use a combination of MVC, MVVM, PM and MVP…and a lot of different variations thereof.
http://davybrion.com Davy Brion
@Rob
First of all, i wouldn’t insinuate that PM is different from MVVM… i nearly got stalked by another knowledgeable MVVM adept (as you are) for saying that
The large majority of MVVM implementations i’ve seen are “Done Poorly”. A lot of ‘big name’ WPF/Silverlight evangelists or bloggers or whatever demonstrate extremely poor implementations of MVVM whenever they can. I’m not going to comment on why that is, but as far as i can see, the very large majority of people who are doing MVVM are doing a very poor job at it. Since they always use the term MVVM, it becomes associated with the poor implementation, so in my view, there’s nothing wrong with criticizing that approach and calling it MVVM… after all, pretty much everyone else calls it MVVM as well.
Now, your idea of a good MVVM implementation might be completely different from what the majority of people who are ‘doing’ (or at least think they do) MVVM, but your idea of it might still not be what many others think is good. I’m not exactly fond of the ‘MVVM Done Right’ implementations either.
And btw, i didn’t say that MVVM is not a valid UI architectural choice. I said that it was highly overrated given all the credit it is getting from a large group of people. There’s a big difference. If you’re going to criticize me for not being accurate, i’d appreciate the same accuracy from you as you’d expect from me.
http://www.caliburnproject.org Rob Eisenberg
Touche! Well, I can’t really disagree with you A lot of “big names” are using the MVVM “marketing” technique to demonstrate what would be bad code under any name. I know at least one person who calls everything he does MVVM, even if it is clearly an anti-pattern. My “version” of MVVM is probably pretty different from the average too. But, I would guess that I have the same motivations in using it as you do in your approach. As I said, context is very important..not just the context of the application but also the context of the corporate culture, developer experience, etc. I apologize for the misrepresentation and perhaps I’ll steal a few ideas from your MVP design
BrianT
Thank you for the article. It has been interesting reading through the responses. I’ll throw another iron into the fire. That is, Rapid Application Development has been tossed out the window. These patterns are part of the problem (not all). I started programming with Delphi about 10 years ago. It was a great tool. Fully object oriented, lot of tools available to speed development and so-on. I created my first order entry application that also implemented SOAP within 3 months. This was right out of college and I had never laid a hand on Delphi before. Our customers were happy, my boss was happy, I was happy.
For the last five years I have been using .net with both ASP.Net and Winforms and within the last year I’ve been working with WPF. Winforms is very much like Delphi in that the form files have code-behinds–just different languages. While jumping on the WPF and separation of concerns band wagon in the last year, I have become quite disappointed. The replies to this post illustrate my frustration. What one person calls MVVM another calls MVP and vice verse.
Upon learning these new architectures (WPF, MVVM, MVP) I have been trying to develop a fairly simple application. The path that I as a developer has to go down is quite frustrating. First, we’re connecting to an IBM ISeries DB2 database. This isn’t Microsoft’s fault but this leaves LINQ out of the question. I then have had to learn NHibernate which hasn’t been a treat and they have their own form of Linq called HQL. Then, I am forced to choose between MVP and MVVM. Because there hasn’t been a consensus on the best one to use, I’ve used my best judgment and went with MVVM. As you can see by the article’s responses, there are different variations (and different opinions) of the best way to implement just one pattern. By themselves, each pattern isn’t fully adequate so then one must gather more knowledge using commanding, IOC patterns, and etc. Furthermore, the examples and articles written about each pattern are very simplistic at best and I’m constantly running into gotchas. Likewise, there are about five toolkits to choose from but I must research them to determine the best one.
I find that the drive for purity is becoming quite costly. What I was able to do in three months has doubled or even tripled my development time. This makes our customers unhappy, my boss unhappy, and myself unhappy. Where I once was able to drop a query object onto a form and be finished I must now create an object class and possibly its interface. Then the model or data access layer. I then have to create a data context with an observable collection (View Model). Before, where the query object would handle the CRUD options, I must handle them myself. Is it really worth it?
http://davybrion.com Davy Brion
@BrianT
it depends on how long the software is going to be kept in use and will require maintenance. With RAD, you’ll obviously get something up and running much quicker, but all of the time you win at first will almost always be lost after the initial development has completed. Not only that, a lot of changes will require an ever increasing amount of time so in the long-run, you typically lose a lot of time, effort and money because of it
Walter
The entire concept of moving to a pattern such as MVC or MVVM to achieve Seperation of Concerns (SoC) and the Single Responsibility Principle (SRP) is just to divide a complex process into more manageable components. The discussion typically evolves into what is a manageable component or “how small is small enough”. At one of the spectrum is the current code-behind, all-in-one usercontrol scenario, which works when the process is perceptually simple. An example might be CRM software for Sales in order to track contacts, visits, etc. At the other end of the spectrum is multi-component, patterned, multi-author software. The issue isn’t about the ends of the spectrum but the middle; perceptually simple for one is complex for another. The discussion has been on-going with software for years: moving from machine-code to compiled languages, from procedural to object-oriented designs, and now from code-behind to patterns. All we’re doing is trying to figure how to colloborate by breaking up the pieces of the process and then who is going to integrate the pieces back into the whole. If we believe a component is doing “too much”, break it down into pieces; if we believe a component is doing “too little”, combine it with something else to eliminate waste or duplication of effort. Some patterns and software shops have defintions for their components to follow based upon experience, practice, and the software application deliverables. I could, technically, devise a pattern where each variable occupies its own model space, perhaps call it Mode-View-ViewModel-Presentor-Control-QuantumVariable-IntegratorModel, which are then integrated into a vast hierarchy of inter-related views, presentors, controllers, etc. If that is what is necessary, then that is what is necessary. Examine the software design specifications and user experience necessary, include the upfront costs and compare against maintaining the code-base for corrections and upgrade, and then determine how to divide your process into manageable components.
Let us see some code to learn from your experience and how you decided to create manageable components.
http://davybrion.com Davy Brion
@Walter
there should be plenty of code in the MVP series which i linked to at the top of the post
pg
I just want to thank Davy for bringing this topic up.
I believe there is a place for something different than MVVM. It all depends on the circumstances, but as it stands today everybody assumes that MVVM is the ‘silverbullet’ but unfortunately it is not that simple and we need alternatives that will help continue evolving our profession.
Lixin
@Walter
My experience on MVVM is totally different. I was also using Delphi and doing simple stuff in C# WinForm in the past. After I saw MVVM, I created a very simple MVVM framework together with a Mediator (or called event aggregator) and it has made my development progress so much faster and easier than before. My experience can be concluded as follows,
1. Using MVVM with WPF/Silverlight’s strong binding support saves a lot of time writing codes on binding. I also used MVP in some of my other applications before and found MVVM is so much time saving with the WPF/Silverlight binding support.
2. MVVM lets me concentrate on my models and viewmodels. That means I normally “produce” code without worrying whether it will work or not because I know it will just work. That improves the efficiency in coding.
3. Mediator or event aggregation eliminates messy event handling in my code. That improves the code readability and also greatly simplifies the code.
Of course if you are doing a very simple application, MVVM might not be better than controlling the UI and processing messages between modules directly.
Pingback: Stuff I’m Reading
Frank
OK,
I hear that MVVM is a fine way for complex user interfaces.
But why would you want a complex user interface?
Isn’t there a way of going along simple User interfaces?
Master
Wekempf – Hi Arron, hows things. You still writing access apps using sql server?
Gizz
“so yeah, i’m truly very sorry that i have to disappoint you that i haven’t spent every single spare minute i had on this so i could put this online as fast as humanly possible for you to read it, not get it, and still complain about it
nobody’s forcing you to be here, nobody’s forcing you to read this, nobody is forcing you to believe anything i’m saying, and most importantly: nobody’s forcing me to spend more time on people like you than i’m prepared to do”
Very well said, sir.
Xzz0195
Couldn’t agree with you more on SOC. When I first read up on the convoluted relay command I was floored. I still like the MVVM but use it in a modified way… ViewModel is only responsible for Binding and backend Model updates. But I don’t pull data into the ViewModel I push it from the Model. After all sending a data ready event is really in my mind a nice Asynchronous and reasonable thing to do. That’s all done in the model. But then what about commands? I actucally create a separate folder and put all my command in one place. Commands should do one thing, Execute a command. If that means waking up the model so be it. The model fires data ready event so everything works nicely. Putting all of this into the ViewModel is, well, it’s ridiculous…IMO

http://simonmassey.clavid.com/ Simon Massey
This concept of “push” or “pull” I think is a key distinguishing factor. Most Model-View-Something patterns diagrams put the components in a triangle. Draw it as stack with the View pulling data through the ViewModel and pushing commands back down and we see that it is a Mediator of the Model.
Slides 30, 31, 25 of this presentation http://www.slideshare.net/simbo1905/design-patterns-in-zk-java-mvvm-as-modelviewbinder come to mind when I read this discussion.
With pure bindings the ViewModel has no compile time references to the View. The Binding technology has a primary role. Draw it as a triangle with the Presenter at one corner pushing data into the View then it is the Mediator which has compile time references to the View. The bindings there are optional (slides 23, 25).

Pingback: Pattern Web Solutions » Blog Archive » What are MVVM, MVP and MVC?
SonOfPaul
I think that every property and every routine or function needs to be in its very own namespace. That way we can have a true separation of concerns. I like to call this approach the VPMFPMFPMFPMFPMFPMFPMFPMFDB approach.
What do you guys think?
Mike
Finally someone who understands my frustration!
Problem is, you don’t back it up with a code sample.
Now I can’t help but feel extremely disappointed, and somewhat angry. People need your code sample!

Mike
I apologize, the code sample has been posted. I missed your update to this blog at the top.
“People wanted code, so i showed them code”…
THANK YOU!

http://profiles.google.com/jordanhammond Jordan Hammond
MVP MVVM, it’s really all the same thing. You could simple change the headings of your preferred pattern to:
Presenter = Model
PresentationModel = ViewModel
and you have the same result. In your communication via a service reference then the model really begins in the client area, not what the server gives you.
Skin it how you will, it’s really all the same thing.

http://davybrion.com Davy Brion
are you really of the opinion that the approach outlined in my series (http://davybrion.com/blog/2010…) is the same as MVVM?

Lochness71
If you have ever designed or created a touch screen or UI with a fluid front end you will love MVVM. If you are still bulding crusty old form based applications… I understand your whining.
Paul
Cool.
So what happened? Did all the people begging for code look at it once you posted it, and finally understand what you were talking about? I notice there was not much further debate after the code got posted.

http://davybrion.com Davy Brion
a lot of people quickly move on to different things once you ask them to focus for more than 2 minutes

Pingback: MVVM design pattern « Suresh Kumar Veluswamy's Blog
Simon Segal
Davy I am in the camp that completely agrees with your view on this and my colleagues and I have taken a route that has merged some ideas from the MVP pattern with some of the ideas prevalent in NServiceBus; these are consistent with Udi Dahan’s approach to design that embraces the notion of making software concrete and intention explicit through use largely of interfaces. MVVM is not a pattern that ever appealed to me in the years of considerable development I have done with WPF.
Spammer
Honestly, I’m doing a small configuration tool with one or two extra dialogs and using WPF and MVVM.
What strikes me the most is the complexity when you go with this pattern. All the people are all over it and I cannot find a solution besides using some extra framework with implementing more than one form/dialog and their interaction.
Maybe I’m alone with this but there is a lot of plumbing for a simple application…
Jp
Without seeing the code, can’t see much difference between your proposal and MVVM. I however, agree on SOC and have voiced dissapproval of the Relay Command and implementation of the call back in the View Model. There’s no way that pattern can be reused. So I use my own version of ViewModels for 1) Binding first and 2) Dependency properties and usually not much else. The view kicks off commands to “Command Central” which is a folder of commands that tell the model to get data. The model then, when ready fires a dataready event of which any Viewmodel can subscribe. The model never knows who’s listening. So the commands are the action items in my patterns in that they respond to the GUI, and alert the Model.
This is very similar pattern to Silverlight RIA. In RIA the ORM becomes an asynchronous callback method that when ready posts the data back. The load of the data is then handled via binding when the source is set in the callback. In fact my MVVM ideas were stolen from RIA.
Rj45thompson
I am no expert in this domain as I am a C++ programmer comming to this web world. We had MVC 15+ Years ago and it works just fine. I may be going to go out on a limb here and say that people should focus on the context of their problem and use interfaces to abstract dependancies. The way you abstract your objects is what seperates men from the boys. Also expect that your home brew pattern won’t even be consistant across your own code if you want it to be the best* possible. You can’t just copy some pattern and have the best solution for your context in almost every case but the most generic.
By just following along some popular flavor of the month pattern code you dragged from the net is the new bane of programming. First you need to understand the basics of programming and how to evaluate what is best. The human mind is a tool which craves properly carved blocks. What is best is how your mind accepts them regardless of any principle. It this way it is an artform, which people seem to have forgot or I am starting to realize people never knew… The first rule is, human ergonomics. Furthermore, contrary to popular belief that may not be pattern at all my friends. Patterns cut blocks into sizes which are incorrect for contexts, therefore they will always be inferior despite consistancy.
Guest
I can’t disagree!
http://simonmassey.clavid.com/ Simon Massey
It can be a bit difficult to discuss an architectural pattern in one language or presentation framework. I wrote a Java patterns demo app with a page done once at MVP, once as a flavour of MVC with bindings, and once as MVVM. Hopefully switching languages/frameworks will help shed some light on what is pattern and what is surrounding context.
The presentation / discussion of the patterns are at http://www.slideshare.net/simbo1905/design-patterns-in-zk-java-mvvm-as-modelviewbinder and the sourcecode is at https://github.com/simbo1905/ZkToDo2
What is interested is what I described as desktop MVC which is using Bindings of the View to the Model. The model is updated from commands on a Composer (a not-so-supervising controller). This seems to me to be what Davy is advocating (MVP+Bindings == MVP+PM). There is a dedicated article on that http://java.dzone.com/articles/using-desktop-model-view
So having (hopefully) shown code for all three patterns discussed here let me wade into the debate…
I agree with @ac2dd23ded65763235b3b439ec326d50:disqus that the hope is that the ViewModel has a single role; to model the GUI. Whether you are going to get a nice coherent ViewModel is down to how much impedance mismatch you are going to get trying to mediate your Model to the View.
By way of an example if your model is something like remote service rapping a dao which is stored procs then your going to have a lot of plumbing to deal with the remote calls and remote errors. If the data you get back is raw database values you are going to want to wrap it with a simple Presentation Model which does the formatting for the screen. That is clearly two concerns which may naturally fall into two sets of classes.
You would be annoyed if you had to maintain code which tried to pretend to be a POCO but which did service lookup and remote calls in its getters (no really, it happens). Such “mystery guest” objects may benefit from a refactor into a business delegate (mediates the remote calls) and a presentation VO (a weak ViewModel or a simple Presentation Model). Having seen such code I am thinking that these are the sorts of messy ViewModels which Davy seeks to avoid. The more logic in the remote service layer; the less there is for the “client side” to do other than just the plumbing, the formatting, and the layout. The more these fall into different SOC classes.
On the flip side if you don’t have a lot of in-your-face remote plumbing between your View and your Model then you might not find there is no problem with a rich ViewModel. Desktop apps are more likely to have less in the way (e.g. some ORM). With almost no Service Layer logic then why not have the ViewModel do mediation of the data access layers? Why not have it be the “app logic” and hold the user session objects and manipulate them then persist them in the services with a View bound onto it?
The best choice is not the pure pattern; the best choice is the one which work in the context of your code and its deployment. If your context works better separating Mediation from Presentation then Davy recommends MVP+PM (or I would call it MVP+Bindings). If you are not getting bogged down in the business delegate plumbing then people are recommending MVVM which mixes both mediation and conversion of your Model to your View.
Guest
No matter what ideas you want to defend, being such arrogant won’t help you in your career and also in your life…
http://www.facebook.com/profile.php?id=1184953582 Albino Cordeiro Jr
Well, you apply the SRP once when you add a reference in the View class to a viewmodel object and you transfer all non-view-related logic on the code-behind and put it in the viewmodel class. Nothing says that you have to stop there. Now you can create a other abstractions (A DataService class, a CommunicationService class, A ValidationService class, etc.) and apply the SRP to the viewmodel class: the viewmodel will have references to objects of those “Service” classes and the responsibility(reason for changes) will be transfered to them.
Satyajeet Deshmukh
Which pattern do you suggest instead of MVVM??

The MVVM Pattern Is Highly Overrated

Meta

Recent Posts

Categories