Home/ Questions/Q 4547500
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T16:06:03+00:00

I’m trying to get to grips with different patterns (MVP, MVVM etc) and find

  • 0

I’m trying to get to grips with different patterns (MVP, MVVM etc) and find one that suits my needs. After all my reading I’m still not sure. Hopefully someone can shed some light on this for me.

At the moment I have a WPF View which implements an interface ICustomView. This interface is injected into my Presenter. The presenter then is responsible for subscribing to data, managing subscriptions etc. When the data is returned to the Presenter it calls various methods against the Model (an IObservable collection of CustomBusinessObjects). It does this using the interface ICustomView since the IObservable is a property of the Model.

The problem I see with this is the Model is too coupled with the View. Also the Presenter is deciding which methods to call against the Model. At the moment the View consists of a WinForms grid and this is exposed by the ICustomView allowing the Presenter to call methods against the View. However it adds to the coupling of Presenter and View which makes it difficult to swap out this WinForms grid for a WPF grid or chart etc

I am considering making the Model an entirely seperate entity lets say IModel with a single method ProcessUpdate(string topic, IMessage payload). This would move logic away from the presenter into the Model. It would also mean more than one view could share the same model. The custom model could have additional interfaces for specific customisations but the Presenter would only need to know about IModel.

Does this sound like a reasonable idea? Am I missing something here?

Any advice appreciated.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would recommend switching from MVP to MVVM because you are using WPF. I would only use MVP if you were using ASP.Net or WinForms.

    That being said, your MVVM objects would be:

    Model: Simple data object. It should not contain any functionality such as Save or Edit, but can have Validation logic.

    View: Your UI. I usually do mine as a DataTemplate for the ViewModel class type. It should bind to your ViewModel’s Properties and Commands.

    ViewModel: The piece that combines the two. Any data displayed in the View should bind to a property in the ViewModel. Any commands in your View such as Button Clicks should also point to methods in the ViewModel.

    For example, when a user hits a GetCustomer button on the View, the ViewModel should receive the command, go and get the CustomerModel, and expose it’s Properties for the View to bind to. When the user hits Save the ViewModel should validate that the Model is valid, and then execute the Save code using its CustomerModel property.

    • 0