MVP - User Controls - Hiding the IView interface from consumers?

1
votes

I would like to use Model View Presenter pattern for a library containing user controls which will be used in other projects.

According to MVP I have to implement an IView-interface on a user control and pass it on to a Presenter-class.

In my case the consumers don't need access to the IView-contract. But because the IView-interface is a public contract it means that consumers of the user control can also access its methods\properties and I want these to be only accessible for the Presenter.

What is a good way to accomplish this?

2
c#controlsmvp
Hello RS Conley Thanks for your response. I don't understand completely what you mean but there's one thing I do that you advice which is not implementing the IView on the user control. Currently I do it like this: In the user control I've created a nested class which accepts the user control in its constructor. The nested class implements IView and knows about the presenter. This way I can hide the IView-contract from the consumers of the control and I handle everything in the nested class. – anagels
That class is just a stand-in for the Control then. What I was getting at is the VIEW is the FORM not the CONTROL even indirectly through a helper class. Only time I can think when a control can be equated with a view is that is a form has multiple tabs each having a view of the model and each of the tabs is implement in a control. Then it would make sense to have a control implementing a view (either directly or indirectly). – RS Conley

2 Answers

1
votes

I've found a solution for my situation.

I make my IView-interfaces internal and implement them explicitly on the user controls. This way the IView-interfaces is not part of the public interface of a user control which is what I need in my case.

0
votes

I always consider User Controls tied to the Views not be a separate view themselves. They should be able to access any Presenter that the view they are tied can access but are not in themselves views. Rather they are part of a view and can be replace or altered without concern to the present if the UI changes.

In your specific example I would have the User control not implement any view interface. Instead I would just have the User Control Assembly reference the Presenter Assembly and have properties to allow access to the View Object that it is a part of.