|
Build errors 2013 ... builds on 2015
modified 8-Dec-16 15:53pm.
|
|
|
|
|
Hate to say it but it builds for me. I downloaded it and built with no problems. Are you using VS 2015. That is required. What errors are you getting. Without detail, hard to debug your problems.
|
|
|
|
|
Yes .. works o 2015 ...thanks ... will try it out and change rate 3
Not an MVVM fan ... a solution looking for a problem to solve that no one appears to have found ... hence so many implementations.
Thanks
Richard
modified 8-Dec-16 15:56pm.
|
|
|
|
|
Interesting that you would only give 3 stars just because you do not believe in MVVM. I have found MVVM to be a good solution. Have to say I have some issues with the implementation. Think there are many places for improvement. Also, I am not sure you are familiar with all that you get with the Microsoft MVVM pattern.
|
|
|
|
|
"3 stars ... it does not offer a solution." to what!
"I have found MVVM to be a good solution." Please explain, i really want to know.
Thanks
Richard
|
|
|
|
|
To Quote:
In MVC, you have a triangular relationship between the components. That is: The Controller owns the View and the Model. The View relies on the definition of the Model. The Model needs to fulfill the requirements of the View. Think of a Hub (controller) and spoke architecture (view and model)
In MVVM, think of that triangle flattening out with each component only knowing about one other in the chain. That is: View->ViewModel->Model
The Model is unaware of anything up the stack. The ViewModel is only aware of the Model The View is only aware of the View Model - it is unaware of the Model.
Why is this important?
This is the core of the original question.
The main purpose is further abstraction of your architecture. This will typically lead to a bit more code, but fewer points of contact between objects. Fewer points of contact are important because this leads to more agile code. The more coupling/contact Class A has with Class B, the more impact a change in Class A will have. Reducing the impact of change is one of the key benefits of good architecture.
To fully understand this, it's helpful to ponder about what the components really represent. What is a View, a Controller, a ViewModel, or a Model? Are they literal definitions, or more of an abstract concept?
In my experience, it has been more beneficial to consider the Model to be a cluster of classes/objects which deal with the construction and persistence of data. It's not just a plain-old-object with properties. It's a class which performs data fetches, data saves, a factory which constructs plain-old-objects. It's a facade layer which provides a clear API into the data. Should this facade layer be referenced directly from the View?
In my opinion, it should not. In MVC, that answer is also "no". The Controller fetches data from the Model. In that regard, MVC and MVVM achieve the same goal. Where the two architectures differ is how the data and the view are linked.
Like the Model, the View can be a collection of classes which in coordination with one another, render a presentation view. This could consist of a View Controller + View in the case of mobile platforms (View Controller on iOS, Activity on Android). In a lot of cases, you need a class to load a view document into memory and update view properties. There's a lot of work to do here. In MVC, the Controller quickly becomes a 'kitchen sink' class - a sort of dumping grounds for anything related to the current user context.
When you multiply this over dozens of potential views within your application, you end up with a lot of deep dependancies between your back-end Model code and your front-end View code. With large Controller classes, these dependencies aren't immediately apparent.
Flattening out your dependencies
MVVM flattens out the dependencies. This creates focus. What is focus? The ability to work on a single piece of functionality without the distraction of all other dependencies. Now you can start writing unit tests on code that was previously deemed untestable.
The View Model acts as a facade between the View and the Model. The View Model caters to the needs of the View - technically the View should own the View Model. If the View requires data from multiple sources, the View Model encapsulates the composition of separate data sources into a single, unified, de-normalized object. If the view needs to call back into the Model or other destinations, the View Model provides hooks and routes the appropriate call.
Consider how a networking patch-panel works. At first glance, this seems redundant - why not simply wire your ethernet from point A to point B. But with experience, you'll understand that a patch panel provides you with a key piece of abstraction which allows you to alter the routes of Point B without affecting Point A. This is what your View Model is doing.
Now that you have a clean abstraction between your View and Model, the consequence should be that your View/Controller is only concerned with presentation. This means it shouldn't be dealing with localization or formatting - it gets data and presents data. Your View Model is an ideal place to put these sort of pre-view data massaging. Let's say you need to filter data based on a criteria. Again, the View Model is knowledgable about the Model data (your View is not) and is a great place to put this sort of code.
Once you start organizing your application requirements in this fashion, your View/Controller code becomes cleaner, and when something needs to change, the implications are more obvious, which leads to fewer bugs.
Testability
One final note on testability: By flattening out dependencies, it makes it easier to inject mock dependencies into your tests. It makes testing easier and more concise. Your View Model becomes something that you can define clear test cases against.
|
|
|
|
|
"A criticism of the pattern comes from MVVM creator John Gossman himself, who points out overhead in implementing MVVM is "overkill" for simple UI operations. He states for larger applications, generalizing the ViewModel becomes more difficult. Moreover, he illustrates data binding in very large applications can result in considerable memory consumption."
Its solves nothing that can't be implemented as is.
Chapter 5: Layered Application Guidelines[^]
|
|
|
|
|
Not sure what the point of was for you attachment. Chapter 5 has nothing on the design pattern for the presentation layer. Even chapter 6 does not comment on the MVVM, MVC or MVP patterns. Chapter 11 does mention MVC (which is over 20 years), but generically or with respect to Web.
|
|
|
|
|
The best you could do was a 2006 page that is really just a comment. That is before WPF was available, and that was the first framework that I know of that was implemented. If it was so bad, think there would be a lot of articles less than a decade old, some with actual data.
modified 13-Dec-16 13:14pm.
|
|
|
|
|
"The Evolution of Model-View-ViewModel" ... see dates
[^]
modified 13-Dec-16 17:43pm.
|
|
|
|
|
I have a question for you. You do not like MVVM. What do you like, and why?
|
|
|
|
|
Here's an interesting read. Jerry Nixon on Windows: Most people are doing MVVM all wrong. Are you?[^]
I prefer not to use MVVM in controls. Prevents clashing with an MVVM implementation of the user of the control. Too many styles and few, if any, concrete standards and fewer frameworks requirements.
What I like ... I love XAML and binding ... ComponentModel, INotifyPropertyChanged is a great start, with great OOP practices reduces complexity.
The title of your article should be renamed BTW.
|
|
|
|
|
This article does have some good points. I still do not understand your issues with MVVM. I do not use MVVM in the control, and the only MVVM in the sample is used between the ViewModel and the control.
modified 14-Dec-16 13:25pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
