17

The things which are supposed to go into the Model are also allowed to go into the View-Model i.e. Public Properties, IDataErroInfo and INotifyPropertyChanged, then what should actually go into the model?

ns12345
  • 3,079
  • 5
  • 41
  • 62

2 Answers2

34

Model

Business Data + Business Logic + Business Rules

View

Application UI

ViewModel

Wrapper Over Model which is easily readable/bindable by View using minimum Effort/Code.

  1. IDataErrorInfo - Should go into ViewModel
  2. INotifyPropertyChanged - Should go into ViewModel. Could also go in the Model if necessary (But not recommended)
  3. Public Properties - Yes of course a Model should have them.
Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
decyclone
  • 30,394
  • 6
  • 63
  • 80
  • 1
    Yuck, Model should be completely independent from the UI. `INotifyPropertyChanged` is a UI concern. I'd *never* implement INPC in the model. The model needs to be as concise and independent as possible. e.g. a "bank account" would never have the responsibly of notifying anything of data changes. – Peter Ritchie Aug 17 '12 at 00:38
  • 1
    @PeterRitchie: I completely agree. You could read (if needed) = (not recommended) – decyclone Aug 17 '12 at 14:36
  • Of course. i.e. a successful compile means you can do a lot of things; it doesn't mean you should. – Peter Ritchie Aug 17 '12 at 15:07
  • @PeterRitchie: As I said, it is not recommended. And I don't state anywhere that you should do it. But, if you are stuck with that, I am not the one that can help you. – decyclone Aug 17 '12 at 15:12
  • "INotifyPropertyChanged should go into ViewModel..." – Peter Ritchie Aug 17 '12 at 15:24
  • And what is wrong with that? I thought you had problems with INPC in Model. Which I clearly state "and Model (if needed)"... – decyclone Aug 17 '12 at 15:29
  • just saying your "I didn't state anywhere that you should do it" contradicts what you said. – Peter Ritchie Aug 17 '12 at 15:33
  • 8
    INotifyPropertyChanged is NOT an UI concern. It's an interface for the notification of changed properties, not more, not less. So it's perfectly fine to use in the Model if you wish. – Marc Nov 12 '12 at 14:19
  • 7
    Actually, having the model implement INPC can save a lot of boilerplate re-passing properties from model through viewmodel to the view. – kasperhj Apr 19 '13 at 11:16
4

Assume you are going to write a batch process for a data load. The batch process will only access the model, thus everything you need to process the business rules divorced from the UI belongs in the model. The ViewModel may have some business rules but only as they pertain to the UI.

In the application I am building, the Views and ViewModels are in one assembly and the Model in another. The model has no references to the View's assembly and only the Model assembly has references to the underlying data store (a combination of Linq and web service calls).

dave
  • 1,567
  • 2
  • 21
  • 34