At my work i’m assigned to a WPF project implemented using MVVM pattern. It has Views with zero code-behind, which is cool. It uses a data-model generated by Entity Framework as the Model (with some other classes), which i doubt to be a proper approach. But the thing that bugs me most is that it has the ViewModel as the thickest layer where all the business logic and application/operation code resides.
Now i’m a novice in WPF/MVVM, but my understanding about the MVVM pattern says that the ViewModel is ONLY supposed to provide with the means to the View so that it can consume the Model, which makes it the thinnest layer of all and my business logic and application/operation codes should reside somewhere else.
I’d really appreciate if anyone can help me out. Am i right or wrong about the purpose of the ViewModel? Should i put my business logic and application/operation codes somewhere else, or just consider the ViewModel as my Business Logic Layer?
Yes I agree with not having business logic in the view model unless it’s very simple math calculation. The company I work at likes to keep all the business logic in the model. I personally think there should be a service layer in your project that handles all this logic though. But yes the view model should concentrate on the view, getting and sending input, preferably updating values/properties by the INotifyPropertyChanged interface. I like to think of the view model as a “Crossing Guard” at a school directing traffic. 😛
– Hope this helps