c# - MVVM: ViewModel and Business Logic Connection -

after doing few projects using mvvm pattern, im still struggling role of viewmodel:

what did in past: using model data container. putting logic manipulate data in viewmodel. (thats business logic right?) con: logic not reusable.

what i'm trying now: keeping viewmodel thin possible. moving logic model layer. keeping presentation logic in viewmodel. con: makes ui notification realy painful if data changed inside model layer.

so give example make more clearer:

scenario: tool rename files. classes: file : representing each file; rule: contains logic how rename file;

if im following approach 1: creating viewmodel file, rule , view -> renamerviewmodel. putting logic in renamerviewmodel: containing list of fileviewmodel , ruleviewmodel , proceeding logic. easy , fast, not reusable.

if im following approach 2: creating new model class -> renamer, contains list of file, rule und proceeding logic interate on each file , apply each rule. creating viewmodel file, rule , renamer. renamerviewmodel contains instance of renamer model, plus 2 observablecollections wrap file und rule list of renamer. whole logic in renamer model. if renamer model triggered manipulate data method calls, viewmodel has no clue data manipulated. because model doesnt contain propertychange notification , avoid that. business , presentation logic seperated, makes hard notify ui.

putting business logic inside viewmodel bad way things, 'm going never that , move on discussing second option.

putting logic inside model more reasonable , it's fine starting approach. drawbacks? question says

so if renamer model triggered manipulate data method calls, viewmodel has no clue data manipulated. because model doesnt contain propertychange notification , avoid that.

well, making model implement inotifypropertychanged let move on better things. however, it's true not possible -- example model may partial class properties auto-generated tool , don't raise change notifications. that's unfortunate, not end of world.

if want buy someone has pay it; if it's not model gives such notifications left 2 choices:

1. the viewmodel knows operations on model (possibly) cause changes , updates state after each such operation.
2. someone else knows operations cause changes , notify viewmodel update state after model wrapping changes.

the first option again bad idea, because in effect going putting "business logic" inside viewmodel. not bad putting all business logic in viewmodel, still.

the second option more promising (and unfortunately more work implement):

• put part of business logic in separate class (a "service"). service implement business operations want perform working model instances appropriate.
• this means service knows when model properties may change (this ok: model + service == business logic).
• the service provide notifications changed models interested parties; viewmodels take dependency on service , receive these notifications (so know when "their" model has been updated).
• since business operations implemented service, remains natural (e.g. when command invoked on viewmodel reaction calling appropriate method on service; remember, viewmodel not know business logic).

for more information on such implementation see answers here , here.