Is There Any Advantage in Passing a UI wrapper to a view

Question

Most of the MVC samples I have seen pass an instance of the view to the controller like this

public class View  
{  
Controller controller = new Controller(this);  
}

Is there any advantage to passing a class which provides access to just the the properties and events the controller is interested in, like this:

public class UIWrapper
{
private TextBox textBox;

public TextBox TextBox
{
get {return textBox;}
}

public UIWrapper(ref TextBox textBox)
{
this.textBox = textBox;
}


public class View
{
UIWrapper wrapper = new UIWrapper(this);
Controller controller = new Controller(wrapper)
}

Answer 1

There's a good series of posts by Jeremy Miller in relation to MVC/MVP triad. In particular you might be interested in part 6 it goes into detail about the comms between the view and the controller.

Answer 2

It depends on your architecture. If you're all on the same tier, then you can go without the wrapper, though I'd probably pass an interface that View implements to Controller. Functionally, and from a coupling perspective, the interface approach and the wrapper approach are equivalent.

However, if UI is on one tier and the controller is on another, then passing/serializing an entire View object might be awkward, or even inefficient. In cases like this, you might want to pass a DTO back and forth, which would be easier to serialize and probably more efficient.

I tend to favor the DTO approach, since if your architecture scales up, all you need to do is serialize and de-serialize.

Also, if your View is complicated and has lots of pieces of data to pass back and forth with the Controller, you might start fighting the Long Parameter List smell with Introduce Parameter Object anyway, which is essentially a DTO.

One more thing for you to chew on: for a complicated View, Controller will end up needing to map lots of pieces of data to various text boxes and other UI controls in the View. The same thing in reverse: View ends up grabbing data from a lot of controls and passing them to various methods in your Controller.

I like separating these two. I give Views a DTO and I consider it the View's job to know where to "plug in" and "plug out" each piece of data. Both View and Controller are now coupled only to the DTO, as far as data is concerned anyway.