9

I don't know MVVM. I always follow 3-layer patter where one layer is UI, another layer is Business layer and last layer is Data access layer.

In this layer we send request from UI to Business layer and Business layer interact with data access layer. In this pattern, everything goes fine then my question why should one learn MVVM. What is the advantage of MVVM. What are the things can be done very little effort using MVVP. Please discuss in detail. Thanks.

RBT
  • 24,161
  • 21
  • 159
  • 240
Thomas
  • 33,544
  • 126
  • 357
  • 626
  • "what are the things can be done very little effort using MVVP" - Do you mean MVVM, or MVP? Because both are three-layered UI design patterns. – Merlyn Morgan-Graham Feb 28 '11 at 12:15
  • What you are describing as 3-layer is ambiguous. Do you mean multi-tier architecture, where the logic of an application is split up between different servers (UI, web services, database layer), or do you mean that your local client application code is split into three? – Merlyn Morgan-Graham Mar 04 '11 at 21:18

4 Answers4

18

The Layers

As opposed to what ppl wrote before me - the MVVM pattern is not about splitting the UI Layer into 3 layers, it's about splitting the UI Layer into two additional layers - The View and ViewModel.

so if we had DAL, BLL, and UI, now we have Model(DAL & BLL) and ViewModel + View (instead of just one layer UI).

it's still 3 layers but orchestrated differently (and if you really think about it - DAL was never really a layer - it's a helper class at most, so the aforementioned 3-layer was in actuality just 2 layers, that are now becoming 3 layers in MVVM).

The Reasons

if you think about it, you'll see that in 3 layers architecture, usually the UI is mixed with presentation code, and application logic code. this violates SRP (Single Responsibility Principle) and is bad for several reasons. in MVVM the UI Layer is separated into two layers. the ViewModel, which is in charge of the Application Logic, and the View, which is in charge solely on presentations.

This allows you three very important things:

  1. better code Maintainability.

  2. easier to work with VS designer and Blend. aka Blendability. (this is arguably the strongest feature of MVVM. It really boosts up productivity)

  3. allows for testing of the ViewModel with automated tests, whereas up until now we had to test the UI itself, and doing automated tests on UI is complex. This is called Testability

on a personal note; I've been writing in n-tier architecture for years. I started practising MVVM a little over a year ago. It could be a rough ride in some times, but man, it's really worth the effort.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Elad Katz
  • 7,483
  • 5
  • 35
  • 66
  • 4
    I think this is the right way to think about MVVM. Really the MVVM should really just be called VVM - it's agnostic about what the view model talks to. Indeed, it's possible to write simple MVVM apps that *have* no model, if you're lazy and put functionality in the view model. – Robert Rossney Feb 28 '11 at 21:34
  • It is important that the Model remains up to the user to define in this pattern, but I think exact use of the words "two" and "three" confuses the issue. But the main thing this answer is missing is rationale behind MVVM vs other MVC derivatives. Blend support is one of them, but MVVM has strong use cases even without blend. Maintainability and testability are good, but are equally fine in other MVC-alikes. Not that my answer is better, since it only links to this type of info. A key piece of info is that loose coupling is done via reflections/events rather than strongly typed interfaces. – Merlyn Morgan-Graham Mar 01 '11 at 02:42
  • 1
    I have to say i disagree. Maintainability is *far* better in MVVM than in MVC, b/c in MVC the controller has two responsibilities - handling interactions with both the Model and the Controller. In MVVM however the ViewModel is only about the logic&state of the application and hence preserves SRP Principle is a much more strict way. This helps making the code much more maintainable, and is the #1 reason why MVVM is better. – Elad Katz Mar 02 '11 at 21:02
  • MVC is a category of design patterns of which MVVM is a close cousin. MVC *can* be written to be almost MVVM-like, since there is no rule set in stone about how concrete or abstract each class is, or which layers are forced to communicate with each other. There are unique features to MVVM (databinding for one), but MVVM itself doesn't guarantee loose coupling. I have seen projects that got it wrong, and testability was hurt as a result. I am not saying the things you said aren't true, just that they aren't complete, and can give the impression that MVVM is a magic bullet. – Merlyn Morgan-Graham Mar 04 '11 at 21:11
  • @Merlyn: MVVM, *implemented correctly*, in the vast majority of WPF/SL applications, is indeed the magic bullet :) – Elad Katz Mar 04 '11 at 23:59
  • "so if we had DAL, BLL, and UI, now we have Model(DAL & BLL) and ViewModel + View (instead of just one layer UI)." This is not correct. Model in MVVM does not include BLL. BLL contains the whole business logic, which is done in VM in MVVM and not in the Model. I also think that the statement " and ViewModel + View (instead of just one layer UI)." is also incorrect. Because in nTier you don't have your business logic in UI, but in BLL, but in MVVM you have your business logic in VM. – Code Pope Nov 22 '17 at 17:20
4

MVVM is for building the UI layer. It is a pattern that enables a very nice interaction between your business objects and the UI-framework. You don't have to change your 3-Tier pattern. MVVM is on another abstraction level.
Here you find a very good video introducing MVVM and probably answering a lot of questions.

HCL
  • 36,053
  • 27
  • 163
  • 213
3

MVVM is arguably a three layer architecture itself. Those layers all exist within the same application.

"3-layer" also sometimes refers to n-tier architecture, which is more about separating the UI, the service layer, and the data layer, onto separate servers. If you have that sort of layering, then MVVM will not replace it. It will only augment the UI layer, splitting it into its own three layers.

Here's a write-up of MVVM that shows some relation between classic MVC, through MVP and MVVM:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Also see my answer to this other question. It explains some of the reason you would use MVVM over older variations on MVC.

Community
  • 1
  • 1
Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183
2

MVVM is specifically relevant to WPF, Silverlight/Moonlight and Windows Phone 7 because it takes advantage of the powerful databinding that is built into these frameworks.

alimbada
  • 1,392
  • 1
  • 12
  • 27