The MVVM Pattern Is Highly Overrated
Posted by Davy Brion on July 21st, 2010
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.
July 21st, 2010 at 4:48 pm
Davy, I totally agree with you, but I’d suggest to take a look at MVC-MVVM hybrid – MVVMC. In this case ViewModel responsible dor data-binding stuff and Controller responsobility is to communicate with the model.
July 21st, 2010 at 5:16 pm
Davy,
I agree with you on an academic level because i am just beginning to work with the various MVVM frameworks (i.e. MVVM Light, Caliburn.Micro, and Prism4), would you be kind enough to post a quick start of your framework with the various pieces broke out correctly?
Thank you,
Stephen
July 21st, 2010 at 5:59 pm
I totally agree. I blogged about the same thing a little while ago MVVM is the New Code Behind
July 21st, 2010 at 6:02 pm
I understand what you are saying – but I’m not sure I agree. The few examples I have seen with dividing the logic between controller and viewmodel has been either awkward or too simplistic for real life. I usually nest a complex viewmodel into several subviewmodels and subviews – and the views have explicit regions that are to be filled with subviews. E.g. IOrderView.OrderHeaderRegion, IOrderView.OrderDetailsRegion. Then I fill the subregions: _view.OrderHeaderRegion.Add(_orderHeaderViewModel.View)…. This way each viewmodel and view becomes fairly easy. I use viewmodel first approach.
The “parent” viewmodel is not agnostic about it’s subviewmodels and views – it has direct references to them (via constructor injection).
Anyway, the viewmodel should just use services to prepare Dtos for display. E.g. _orderLinePresenterFactory.Create(_orderlines). And communication is also triggered by the viewmodel by calling some serviceLayerProxy. I don’t see the problem her . Could you provide a code sample to clearify things ? (not too simplistic, maybe with some events from the view)?
(About the sidenote: I have noticed this too. There are some extremely skilled gurus out there with very bad clientside code – surprisingly.
July 21st, 2010 at 6:28 pm
It all depends on your definition of responsibility. In your example above, the 2 “responsibilities” of the ViewModel are not really 2 responsibilities – more like 2 tasks necessary to fulfill 1 responsibility. “making data (from the Model) available so it can be displayed” can easily be thought of as contained in the “communication/interaction with the Model” responsibility. Likewise for your 3 View responsibilities. The real responsibility of the View – to display the UI – is quite simple. All the complications that enable that responsibility are really not that important. You could sit down and come up with a list of a dozen or more View “responsibilities” if you wanted to get detailed enough. But ultimately, all those tasks are working toward fulfilling the same responsibility – displaying the UI – which is all that SRP means.
I have worked on a project where the Presenter logic was separated from the presentation of the model. It was a lot of extra work and we all agreed when the project was over that it was going to be a maintenance nightmare. The reason is that about 1/2 or more of the code in the Presenter and the PresentationModel is duplicate code. What’s the point of creating a separate PresentationModel when the Presenter already has to retrieve the Model object and do work with it? Why not just expose it to the UI from the Presenter (ViewModel)? Is it really all that more complicated to add a property? No – it’s much less complicated than duplicating all the code to retrieve the Model objects from the service in each Presenter/PresentationModel class.
There is nothing wrong with the pattern you describe really, but I see it, particularly based on my experience, as overkill.
July 21st, 2010 at 6:33 pm
I second a concrete example to show us what the implementation looks like.
July 21st, 2010 at 6:56 pm
yep, show me the code!
July 21st, 2010 at 7:16 pm
@Stephen
“would you be kind enough to post a quick start of your framework with the various pieces broke out correctly?”
i’ll try to get something like that up soon, though i can’t really promise when that will actually be
@Lars-Erik Roald
“Anyway, the viewmodel should just use services to prepare Dtos for display. E.g. _orderLinePresenterFactory.Create(_orderlines). And communication is also triggered by the viewmodel by calling some serviceLayerProxy. I don’t see the problem here.”
like i said: i think the PresentationModel should focus (almost) exclusively on making data-binding possible. That means providing the necessary properties that raise the PropertyChanged event, as well as the ones that don’t need to raise that event. For some properties (whose values are used by ‘calculated properties’) that also means raising multiple PropertyChanged events. I think those things are one distinct responsibility and i really don’t want any communication with the model to be mixed with that, since that is (IMO) a completely separate responsibility
@Ryan
you can make your responsibilities as coarse-grained or fine-grained as you want. If you consider “displaying the UI” to be one responsibility, then we obviously disagree. If that were one responsibility, you could consider everything that is *required* to display the UI (for instance, fetching the data) to be a part of that same responsibility. In that case, you could just as well put it all in the code-behind because it’s all part of one responsibility anyway and you wouldn’t be in violation of the SRP. I really can’t look at it that way.
‘making data (from the Model) available so it can be displayed’ is what i consider to be => facilitate data binding. As mentioned in the post and earlier in this comment, i don’t consider that to be related to retrieving the data from the model. To me, both are separate steps and should be dealt with separately.
“I have worked on a project where the Presenter logic was separated from the presentation of the model. It was a lot of extra work and we all agreed when the project was over that it was going to be a maintenance nightmare. The reason is that about 1/2 or more of the code in the Presenter and the PresentationModel is duplicate code.”
I really don’t understand this… we _never_ have duplicate code between our presenter and our presentation model. I can’t even think of a way how you could end up with duplicate code between them if your presentation model just facilitates data-binding while your presenter communicates with the model. The presenter doesn’t have the same properties as the presentation model… it contains the presentation model and uses it to store the data retrieved from the model. If the data can be modified by the user through the view, the presenter can then retrieve the modified data from the Presentation Model and send it back to the model.
Maybe there’s something you misunderstood about our approach with regards to the duplicate code thing… could you provide more details of what kind of code would be duplicated in both places? Keeping in mind that our presentation models are incapable of communication with the Model of course…
“There is nothing wrong with the pattern you describe really, but I see it, particularly based on my experience, as overkill.”
in our experience, it actually ends up making things simpler
July 21st, 2010 at 9:14 pm
*sigh*
“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.”
Presentation Model and View Model (or Model-View-ViewModel, see http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!797.entry?sa=547377752) are one and the same pattern. All of your complaints aren’t really about the pattern, but about how the pattern is implemented, as evidenced by this one mistake in not knowing that Presentation Model and View Model are two names for the same pattern.
July 21st, 2010 at 9:15 pm
@Wekempf
what part of ‘slimmed down version’ did you not understand?
July 21st, 2010 at 9:16 pm
Davy,
I have a ‘feeling’ that the next version of C# will be more like Objective-C and intercept messages and automatically notify anyone subscribing. At this point, would you get rid of your presentation model classes and just expose the properties and other events directly on your presenter?
July 21st, 2010 at 9:19 pm
@Josh
that wouldn’t be sufficient in the case of ‘calculated properties’ so no, i wouldn’t
July 21st, 2010 at 9:25 pm
Makes sense. Which class is in charge of determining which view to display, and how does it go about making the view actually show up in the ui in the first place?
July 21st, 2010 at 9:34 pm
@Davy Brion, what part of “PM and VM are the same pattern” did you not understand? I could care less if you slim it down, it’s the same pattern. You can’t say you don’t use VM, then turn around and say you use a slimmed down PM. Seriously. You’re points about SOC and SOLID are valid, but violation of these principles can be done when implementing ANY pattern. VM doesn’t lead to the problem here, and you can follow VM without violating SOLID principles. AS YOU JUST ADMITTED TO DOING.
July 21st, 2010 at 9:35 pm
@Josh
We always have one ‘root’ control which is the one that is instantiated initially upon application start-up. Since we use MVP instead of MVC, the View is created first and resolves the presenter through the IOC container. So, the root UI component is instantiated, it resolves its presenter and from there on, it kinda depends. If there’s a menu, we’ll (obviously) go to the View of the selected menu item. If it’s a dashboard-kinda interface, there’s usually multiple views through which the user can navigate to other parts of the application.
Not entirely sure if this is what you wanted to know, so if i missed the intent of your question, feel free to ask it again in a different manner
July 21st, 2010 at 9:36 pm
IMHO, you are doing MVVM. You have a model, a view and a view model/presentation model. Much like the observer-pattern (very general) can be done with sinks, delegates/events, etc, the concept is the same even though the implemenation is very different.
-Jer
July 21st, 2010 at 9:47 pm
@Wekempf
“I could care less if you slim it down, it’s the same pattern”
if the behavioral part of the pattern is missing or significantly different, then clearly, we can’t really consider them to be identical, no? Our presentation model does NOT have any kind of behavior outside of what is necessary for data-binding. It does NOT communicate with the Model, which is a very important part of the ViewModel pattern, right?
Now, in that sense, the Presentation Model is probably a poorly chosen name… Then again, some people consider Presentation Model and ViewModel to be the same, and others don’t. You make of it what you want, and i will make of it what i want.
“You’re points about SOC and SOLID are valid, but violation of these principles can be done when implementing ANY pattern.”
Depends on how you implement the pattern and it also depends on how high-level or low-level the intent/description of the pattern is. In the case of MVVM, the pattern is pretty clear: communication/interaction with the model is done in the VM, which is what i consider to be a serious violation of the SRP. In our approach, that violation is not present.
“VM doesn’t lead to the problem here, and you can follow VM without violating SOLID principles. AS YOU JUST ADMITTED TO DOING.”
once again: VM is supposed to interact with the model, which results in the violation. And no, i didn’t admit to doing that… you are too hung up on the usage of the Presentation Model name. If you would actually _think_ about the difference between my version of the Presentation Model, and the widely used definition of the ViewModel, you can’t seriously consider them to be the same.
Would it help you if i renamed my Presentation Model to a SloppyJoe or something like that?
July 21st, 2010 at 9:51 pm
@Jeremiah
i disagree… a very important part about any pattern is how you deal with behavior. if the behavior is dealt with in a different manner, then you can’t consider them to be the same
it’s like saying MVC and MVP are the same
large similarities still doesn’t mean it’s the same
July 21st, 2010 at 9:54 pm
@Davy Brion
“If you would actually _think_ about the difference” implies I haven’t, which isn’t evidenced anywhere in my responses. It’s rather offensive. If you’d not “underlined” the think I could forgive it as a misunderstanding, but at this point it’s rather obvious you’re flaming. Going to make it very hard to have an intelligent conversation about the topic, so I’m bowing out. Have fun splitting hairs with anyone that cares.
July 21st, 2010 at 9:59 pm
@Wekempf please behave. Let Davy have time to create some example code.
And, yes, the concepts are easy to mix – because one pattern is a specialization of the other.
Splitting databinding and communication handling sounds appealing to me – but I just don’t believe it yet…but I might change my mind when I see the code.
July 21st, 2010 at 10:00 pm
@Wekempf
The fact that you keep going on and on about how it’s the same while there is a major difference in the implementation and that you keep focusing on the name does kinda imply that you didn’t really think it through IMO
If you consider that to be flaming, that’s too bad.
though i’m glad that we can at least agree that the usage of all caps is different from using ‘underlining’ when it comes to flaming. even though our reasons to agree would differ.
July 21st, 2010 at 10:03 pm
@Lars-Erik Roald
it’ll probably be either during or after the weekend though
July 21st, 2010 at 10:15 pm
This article’s points (UI independence, Separation of concerns and SRP) don’t really argue in favour of going back to code-behind. they argue if favour of going to MVVM and then going further.
If you feel that the ViewModel is doing to much, then yes, split the actions out into command classes that work upon it and leave the viewModel just as a source of binding data.
July 21st, 2010 at 10:19 pm
“This article’s points (UI independence, Separation of concerns and SRP) don’t really argue in favour of going back to code-behind. they argue if favour of going to MVVM and then going further.”
well yeah… going back to code-behind is something i’d never recommend and MVVM is just not good enough IMO
July 21st, 2010 at 10:28 pm
@Lars-Erik Roald
Behave? Really? What did I do that wasn’t behaving?
@Davy Brion
The all caps were making a point through emphasis, not flaming. You’re underlining also was for emphasis, but what was emphasised was a flame. There’s a distinct difference here.
BTW, as evidenced by the blog post I linked to, I’m hardly hung up on the name, beyond the need for clarity in communication. I don’t care what name you use, you stated that your code followed the pattern. You do split hairs about the implementation, but patterns aren’t about implementations. Based solely on your description, what you’ve done fits the VM pattern, even if you implemented differently than someone else has. So, my issue isn’t with the technical merits of your design, but with yet another “my implementation is different from yours so I must be using a different pattern” posting that just leads to further confusion.
July 21st, 2010 at 10:35 pm
@Wekempf
“You do split hairs about the implementation, but patterns aren’t about implementations.”
Well, that is something that we just fundamentally disagree on then. It’s not about the actual implementation on a line-per-line basis, but i do consider where you put certain behaviors to be a very important part of a pattern description/definition, especially when you’re talking about high-level patterns like MVVM, MVP or MVC
July 22nd, 2010 at 3:20 am
Put me on the list of those interested in some sample code! =) I’ve been trying to deal with the same issue you have, though I’m a neophyte in both WPF and MVVM.
July 22nd, 2010 at 6:49 am
I created some examples of “View Model”. Basically it is like MVVM, but concentrates on using less code than you would need for code behind and also allowing the Designer full freedom to change the design.
RIATasks: A Simple Silverlight CRUD Example
http://www.codeproject.com/KB/silverlight/RIATasks.aspx
July 22nd, 2010 at 9:17 am
Davy,
It will be interesting to see some code examples to illustrate your points. I don’t think your message is clear enough without it.
July 22nd, 2010 at 9:39 am
[...] The MVVM Pattern Is Highly Overrated – Davy Brion discusses what he sees as some bad aspects of the MVVM pattern, focusing on how it doesn’t correspond to many of the principles usually held in high regard in software development. Lots of interesting discussion in the comments on this one. [...]
July 22nd, 2010 at 12:07 pm
[...] 22, 2010 The Inquisitive Coder recently made a post about MVVM being overrated. He states a preference for MVP (a great pattern, and a great [...]
July 22nd, 2010 at 1:35 pm
It’s an interesting discussion point. From what I can tell, everyone sensible agrees on a separated presentation layer, which xaml enables nicely, but the rest of the debate is just semantics and implementation details.
It is axiomatic to say that anyone who is doing separated presentation smelling design will have to create a class or classes which provide the incoming and outgoing binding interface of a particular view. On top of that, a further set of infrastructure classes will probably be needed to instantiate and manage those binding classes and the views. How you design the non-presentation layer is interesting and important, but the best approach depends on a number of factors, e.g. project complexity, team size/project methodology, future requirements and projects, requirements for plugability, testability, design requirements…….
Some implementations will be better than others, so I vote for the code sample. 500 lines of code will tell 5000 words, and will take the reader 1/50th of the time to comprehend the meaning of your take on this.
July 22nd, 2010 at 1:39 pm
as mentioned earlier: a detailed code sample will be posted during or after this weekend
July 22nd, 2010 at 1:39 pm
I would go for MVVMP, namely Model View ViewModel Presenter pattern. The presenter interacts with the model and translates data from the model into bindable data which is attached to the ViewModel.
July 22nd, 2010 at 3:22 pm
We use a variant of MVVM pattern, wherein we have Model, View , ViewModel and Controller. The controller can further have micro-controllers. Our ViewModel has only properties which are needed by the view. It delegates all other responsibilities(which you have mentioned above) to the controller using events or mediator pattern. The controller can delegate a request further to a micro-controller. It it the responsibility of the controller to talk to the model and populate ViewModel properties. This approach facilitates SOC and SRP.
The MVVM pattern is highly overrated because it allows unit testing at all levels. Further, you can write do end-to-end testing by simulating clicks(using commands). MVVM is a great pattern if you use it correctly.
July 22nd, 2010 at 8:15 pm
The view model in the mvvm pattern is just that : a model of the view. I would not presume most of the business view that I write to be a mere display of static values. A view model has properties as well as behavior (buttons, property selections, sliders). Now, i saw a reply stating that mvvm is the new code behind as I’f it was a bad thing when in fact, this is the whole idea of the pattern! Make the code behind completely independent of the guy, so that you can unit test the GUI behavior.
Honestly, I fail to see the authors point. Does it violate SRP? No! The VM has one single responsibility, and that is to represent a GUI. Are there separate concerns? Again no. One could argue that the VM holding a service reference might give a few extra headaches, but for all intents and purposes, at some point, a service reference to the view must be made.
I’ve had some concern about the complexity of the view model classes myself ,but realized after some time that I was trying to do too much in a single view, something that has led me to keep my views simpler. And the effect? Customers love it.
July 22nd, 2010 at 8:20 pm
@Pedro
one simple question: should all logic of handling a service request be implemented in one single class? If your answer to that question is yes than you indeed fail to see my point. If your answer is no, then i’d like to ask you: what is the difference?
after all… handling the service request is the only responsibility, right?
July 22nd, 2010 at 9:07 pm
The view itself has one responsibility, and that is to connect th non-gui end of some service class to the end user. This involves 2 aspects: the graphical bit, and the code thAt connects it to the service.
The typical example, some input form with an OK and CANCEL button, a list of possible values for a property etc.
The view itself a listbox, some text boxes and a couple of buttons.
What you need to back these are
- properties to hold your values
- some services to supply you with listbox contents
- some service to chew on the users input.
All of these tied together form the dreadful code behind. This is where your SOLID principles meet at the end, right at the end users nose.
If, during testing, a end user finds that something odd happens if he clicks that button before the other one, that is now something that you can create a reliable test for. You don’t have to set up a bunch of satellite code to recreate the problem, you just ask the view model to press this and that button, possibly with the services moq’d away.
The VIEW as I have come to understand the pattern, is an isolated user experience, a scenario that helps the user solve a particular task. The view model is where all of the SOLID principles come together to support it, almost in a cucumberish way.
HOWEVER, and this is important:
You Are right in that traditional view design, such as a complex order form can quickly lead to completely ridiculous viewmodels. The trick is to apply SRP to the design itself. Separate the view concepts as rigidly as you do the code, and you quickly find that bloat is a thing of the past. Hints: start out by creating a view for every value class you have. Remember that view models can and should contain view models. Binding directly to data is a no no. An OrderViewModel class should naturally have an observablecolection of OrderLineViewModels, a CustomerViewModel, etc. These are all individually fortified by unit tests. I see far too many people complicating their lives by having that orderviewmodel contain a list of ordereline objecs. This leads to instant code bloating, and violates at least half a dozen principles.
Some of my most complicated views are all designed like this, and rarely consist of more than two or three properties, some event stitching (I do use the. Mediator/EventAggregator pattern with mvvm). IOC takes care of the object stitching for me.
July 22nd, 2010 at 9:41 pm
@Pedro
“The view itself has one responsibility, and that is to connect th non-gui end of some service class to the end user.”
As i’ve mentioned before, that is way too coarse grained. Retrieving data from the Model, transforming it a ViewModel structure/hierarchy, notifying the View of changes, and sending changes back to the Model is currently all concentrated within the ViewModel… i really can’t agree on all of that being ONE responsibility
“The view model is where all of the SOLID principles come together to support it”
grouping a bunch of code together in one class is does not mean you’re writing SOLID-compliant code… i think there will be very, very few situations where that actually turns out to be the case
You really don’t have to take my word for it… maybe it’ll help if we involve code metrics into this discussion. Good OO code is highly cohesive, and loosely coupled. Loose coupling is easy to achieve, but writing cohesive classes is another matter that very few people seem to be capable of doing.
Cohesion of a class increases as its fields get used by most (if not all) of its methods. As you keep piling on extra logic in a class, cohesiveness obviously decreases, unless most of the fields are still being used by most of the methods that implement that extra logic.
Now, as i’ve stated in the post and in my comments, the ViewModel simply does too many different things. Can you at least agree with me that this decreases the cohesiveness of the ViewModel? And if so, how do you think that relates to how well it’s following the SOLID principles?
July 23rd, 2010 at 1:38 am
I like the MVCVMPCMVMP pattern. Model-View-Controller-ViewModel-PresenterController-ModelViewModelPresenter. Guaranteed to keep me in employment for at least 5 years while everyone else tries to figure out exactly what the hell it does.
July 23rd, 2010 at 11:19 am
I am currently working on a movie inventorizer application. Among other things, a movie has a concept called “A format”, which denotes if it’s a DVD, VHS, Blu-Ray, or some other format. The domain object is straight forward:
public class MovieFormat
{
public int Id{ get; set; }
public string Name{ get; set; }
}
Because this is a concept that I wish to visualize, I write a view for it:
(took out the non-essencials). I hope XAML lends itself well for pasting into this reply
(In case it doesent: It’s really just a small grid with two bound properties: an icon, and the name of the format)
Now all that is missing is the viewModel:
public class MovieFormatViewModel : BaseViewModel
{
private IMovieFormatIconManager _iconManager;
private MovieFormat _movieFormat;
private WriteableBitmap _iconFile;
public MovieFormatViewModel( MovieFormat movieFormat, IMovieFormatIconManager iconManager )
{
_movieFormat = movieFormat;
_iconManager = iconManager;
}
public WriteableBitmap IconFile
{
get
{
if( _iconFile == null )
ResolveIconOrUseDefault( );
return _iconFile;
}
}
public string FormatName
{
get
{
return _movieFormat.Name;
}
}
private WriteableBitmap ResolveIconOrUseDefault()
{
if( _iconManager == null )
throw new InvalidProgramException( "No icon manager found" );
WriteableBitmap result = _iconManager.GetIconForMovieFormat( _movieFormat );
if( result == null )
return _iconManager.DefaultMovieFormatIcon;
return result;
}
}
At the risk of repeating myself into stupidity, the whole idea behind the MVVM pattern is to represent a view through a class.
I believe that what you are not seeing is that a view is as isolated as code that follows the SOLID principles. You do not write one huge class for an entire operation, such as “create order form”; a view is not analogous to a form in WinForms. It’s analogous to a domain object.
At a later stage, there will be a MovieEntry:
public class MovieEntry
{
public Movie Movie{ get; set; }
public MovieFormat Format{ get; set; }
public StorageLocation StorageLocation{ get; set; }
}
..with a corresponding view and viewmodel class:
public class MovieEntryViewModel
{
private IMovieEntryManager _movieEntryManager;
private MovieEntry _movieEntry;
private MovieFormatViewModel _movieFormatViewModel;
public MovieEntryViewModel( MovieEntry movieEntry, IMovieEntryManager movieEntryManager )
{
_movieEntry = movieEntry;
_movieEntryManager = movieEntryManager;
}
public MovieFormatViewModel MovieFormat
{
get
{
if( _movieFormatViewModel == null )
CreateMovieFormatViewModel( _movieEntry.Format );
return _movieFormatViewModel;
}
}
// etc...
I do hear your arguments. From my example, I am guessing that you do not like the manager objects injected into the viewmodel classees, and this is where we differ in our opinions.
If you can come up with a MORE cohesive way of writing this code in a different pattern, then by all means, I am willing to learn it, but so far, MVVM is the most testable, easy-to-read pattern that I’ve had the pleasure of working with.
July 23rd, 2010 at 11:37 am
@Pedro
“a view is not analogous to a form in WinForms. It’s analogous to a domain object. ”
I disagree since that doesn’t translate to task-based UI’s at all.
“From my example, I am guessing that you do not like the manager objects injected into the viewmodel classes, and this is where we differ in our opinions. ”
indeed… to me, those ViewModel should focus on facilitating data-binding but should not interact with the model in any way. In my upcoming sample, i’m going to rename them to BindingModels to (hopefully) make the intent and the difference more clear.
Btw, apart from interacting with the Model in the ViewModels, i do think we agree about ViewModels containing other ViewModels… though in my case, it would be BindingModels with no additional logic… that’s going to remain in the Presenter
July 23rd, 2010 at 12:08 pm
I look forward to seeing your example.
Please also include one or two of the tests, I’d love to see how readability on those are compared to mine:
[TestMethod]
public void PressDelete_ViewModelContainsMovies_MovieCountIsDecreasedByOne( )
{
// Arrange
MovieEntriesViewModel entriesViewModel = CreateTestableEntriesViewModel( );
int initialEntryCount = entriesViewModel.Entries.Count( );
int expectedCount = initialEntryCount - 1;
// Act
entriesViewModel.PressDelete( );
int resultingEntryCount = entriesViewModel.Entries.Count( );
// Assert
resultingEntryCount.ShouldEqual( expectedCount );
}
July 23rd, 2010 at 3:22 pm
about the code samples: i’ve given this some thought and i’ve decided to write a series of posts about this topic… one post would grow too large and most people simply don’t read those thoroughly
i want to get the series up as soon as possible, but i do want to take my time for it, so it’ll probably be online within the next 2 weeks instead of this weekend
the style of the series will be very similar to that of the Build Your Own Data Access Layer and Request/Response Service Layer series
July 23rd, 2010 at 3:36 pm
While I find the semantic argument of MVVM vs. MVP vs. SloppyJoe uninteresting, I am really looking forward to a code sample as well. Thank you being willing to go above and beyond to respond to the critiques in the comments and give us all a chance to learn from what you’ve done. And for being direct in challenging the seeming dominance of the MVVM pattern in SL development these days.
I am pretty new to the MVVM pattern, but after working with several MVVM-style applications, I also get a bad feeling when I see a ViewModel holding a service reference (or what Pedro calls a manager) to communicate with the model. If nothing else, it can also lead to problems when you stack up view models and suddenly have a whole mess of possibly redundant service calls being made.
July 23rd, 2010 at 6:02 pm
Interesting article. I also tend to keep data retrieval (and associated error handling) logic outside of my ViewModel, but instead I have that logic in my Commands.
For example, I would have a GetDataXCommand that takes care of getting data X from the model and returning it (I use a custom command class that notifies listeners of a result when complete), and I expose an instance of that command (via IoC container) as a property of my ViewModel. Unlike the pattern you described I still have to take action within my ViewModel on that data to update the appropriate properties in my ViewModel, but that’s pretty light-weight and doesn’t feel wrong to me.
Anyway thanks for bringing up some good points.
July 25th, 2010 at 4:13 pm
I am very new to silverlight, and I am mostly learning now the different patterns used.
I am however fairly experience in web development using the MVC framework.
The pattern you describe Davy seems to match exactly what I have been doing with MVC.
A service layer, which will retrieve the data and return Models (mostly Data Containers)
These Services are injected in the controllers
The controller makes the necessary calls to the different services and create a ViewModel that makes it easy to display the View.
So to me, your approach really makes sense, and that’s probably the way I would naturally build an application now, but I’m not sure about 1 aspect. The web is stateless, which is the reason why we dont interact with the ViewModel, but rather with the Controller which will returns us a brand new version of it.
But Silverlight or WPF, on the other hand is stateful. You do want to leverage 2 ways databinding, It is convenient that the View can talk to the ViewModel, which in turns will trigger some events.
Probably I don’t see the whole picture of the problem, but I like the clean demonstration from Pedro. If the code is easy to read, easy to understand, easy to test. Well, to me that looks very much like easy to maintain… And that’s what we are after.
Now I am very eager to see your code examples to understand better how all those components are wired up.
July 26th, 2010 at 6:54 pm
Can’t say i agree with much of this.
First, I don’t understand why you say that databinding is part of the responsibility of the VM. The reason MVVM works with WPF/SL so well, is that databinding is handled by the framework. It’s kind of like having a class thats serializable and saying that serialization is on of it’s responsibilities.
“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”. You have a class and it raises events based on it’s internal logic. Why is this a problem?
I also don’t understand why it’s a problem that the VM has to handle of exceptions from the Model. Let’s say I have a VM for an email client. Don’t I want to let the user know that an error occurred sending their message?
If I put a layer (or ten) of mediation between my V and VM you still don’t avoid this problem. Right?
Finally when you say the MVP(resenter) is a cleaner pattern because the Presenter’s job is “making data (from the Model) available so it can be displayed”, not only do I think this is a bad description of what the presenter does, but it does precisely the two things you say the VM shouldn’t do.
July 26th, 2010 at 8:19 pm
@Mgd
“First, I don’t understand why you say that databinding is part of the responsibility of the VM. The reason MVVM works with WPF/SL so well, is that databinding is handled by the framework. It’s kind of like having a class thats serializable and saying that serialization is on of it’s responsibilities. ”
i didn’t say that databinding was something you need to do manually. When i say: ‘facilitate databinding’ then i certainly don’t mean manually putting all of the data in each control.
“You have a class and it raises events based on it’s internal logic. Why is this a problem?”
if that’s all it does, then there is no problem
“I also don’t understand why it’s a problem that the VM has to handle of exceptions from the Model.”
if it’s doing a bunch of other stuff as well, then there certainly is a problem with it. once again, classes that do too much are usually a bad thing
“Let’s say I have a VM for an email client. Don’t I want to let the user know that an error occurred sending their message? ”
did i in any way suggest that exceptions from the model should be ignored just because i said the VM shouldn’t handle those? I said that doesn’t belong in the VM, that’s not the same as saying that they should just be ignored.
“If I put a layer (or ten) of mediation between my V and VM you still don’t avoid this problem. Right?”
i dunno… why do you not mind putting a layer (or ten) of mediation between your View and say… the database?
“Finally when you say the MVP(resenter) is a cleaner pattern because the Presenter’s job is “making data (from the Model) available so it can be displayed”, not only do I think this is a bad description of what the presenter does, but it does precisely the two things you say the VM shouldn’t do.”
exactly, because the _VIEW_Model should focus on making things easier for the VIEW (ie: facilitate databinding) and that’s not what the Presenter would do
did you interpret my post as saying that the Presenter should do everything that you’re currently doing in the ViewModel? That’s not what it’s about but your comment seems to suggest that it is
just for the record, i’d like to know what kind of stuff you _don’t_ put in the VM…
July 26th, 2010 at 9:30 pm
1) I didn’t say manual databinding either. But how does the word \facilitate\ change anything? Databinding is NOT a responsibility of the view model class, any more than serializing is responsibilty of class that’s ISerializable, or enumerating is to a class that’s IEnumerable.
2) \if that’s all it does, then there is no problem\. Then we’re agreed; there’s no problem. Glad you changed your mind about this.
3)Regarding exception-handling in the VM– by your logic any class that handles exceptions is doing too much. Logging? Resource cleanup? Again, I think you are abusing the notion of Separation of Concerns. They shouldn’t be handled in the VM, but not ignored either. Still don’t understand.
4) The reason I think database access and and the view model should be decoupled from each other can be approached in various ways. On the most general level, I would say that it’s hard to concieve of how you would achieve testability and extensibility without such a decoupling.
5) You have to explain to me the difference between \making data (from the Model) available so it can be displayed” and \ facilitates databinding\. If my comment suggests that I think your post is saying that the Presenter should do what a VM does, it is because that is in fact what your post says.
6)The viewmodel is an extremely simple concept. It’s the repository for the data and commands that are exposed to the view. Sometimes it needs access to external services to get that data. Sometimes it needs to perform operations via those services. So my VM would contain references to the data and services needed to do 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.
July 26th, 2010 at 10:08 pm
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.
July 29th, 2010 at 9:24 pm
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.
July 29th, 2010 at 9:35 pm
@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
July 29th, 2010 at 10:02 pm
@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.
July 29th, 2010 at 10:12 pm
[...] you can probably tell from my reaction, i got pretty pissed off. Normally, i don’t let comments like that get to me. But in this [...]
July 29th, 2010 at 10:24 pm
@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!
July 30th, 2010 at 11:59 am
it’s obnoxious comments like those which give anonymous, socially impaired blog commenters a bad name
July 31st, 2010 at 6:38 pm
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…
August 1st, 2010 at 8:44 pm
[...] The MVVM Pattern Is Highly Overrated [...]
August 1st, 2010 at 11:33 pm
There is a name for guys like @JustTalk: TROLL.
August 2nd, 2010 at 2:45 pm
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.
August 2nd, 2010 at 2:49 pm
@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
August 3rd, 2010 at 10:10 am
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.
August 3rd, 2010 at 10:19 am
@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
August 3rd, 2010 at 7:15 pm
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.
August 3rd, 2010 at 7:44 pm
@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.
August 3rd, 2010 at 8:01 pm
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 
August 9th, 2010 at 10:32 pm
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?
August 10th, 2010 at 10:04 am
@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
August 10th, 2010 at 4:34 pm
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.
August 10th, 2010 at 4:49 pm
@Walter
there should be plenty of code in the MVP series which i linked to at the top of the post
August 10th, 2010 at 5:43 pm
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.
August 11th, 2010 at 5:35 am
@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.
August 13th, 2010 at 5:43 pm
[...] agree with all his points across his blog but at least he raises them and stands by them. http://davybrion.com/blog/2010/07/the-mvvm-pattern-is-highly-overrated/ http://davybrion.com/blog/2010/08/mvp-in-silverlightwpf-series/ [...]
August 22nd, 2010 at 8:03 pm
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?
September 2nd, 2010 at 5:12 am
Wekempf – Hi Arron, hows things. You still writing access apps using sql server?