Reputation: 11
My application must support different UI’s (Win Forms and WPF). This means I have to encapsulate the business logic. How would you do this?
E.g. WPF with MVVM:
1) Should I introduce a layer between my model classes ( e.g. car, door,…) and the viewmodels? For example by control classes, manager classes, or service classes??
2) Or should the model classes ( e.g. car, door,…) itself contain the logic?
Upvotes: 0
Views: 304
Reputation:
Model classes typically are used to transfer data to and from whatever UI layer you have and your business logic. So they generally shouldn't contain any logic.
I haven't tried supporting both WPF and winforms (and can't honestly come up with a single reason why this would be necessary), but AFAICT winforms doesn't support MVVM well at all. Yeah, you can do bindings (sort of), but you can't, for example, bind ICommands to buttons.
So, I'd suggest using the ViewModel as a bridge between your UI and your business logic. Then, share the business logic classes themselves between applications. Your view models should be very thin and relatively easy to create and maintain. A similar bridge may be useful in the winforms project, or perhaps just simply re-create your view model code in codebehind.
Upvotes: 0