How would you use the MVC pattern with Winforms when it comes to using ListViews?

Question

My old way of handling WinForms application was throwing all the logic into the form itself.

I'm trying to start utilizing MVC/MVP practices with my WinForms applications.

Can someone show me an example of how I would use MVC/MVP in conjunction with say, a ListView? I use to use the Tag property of the ListView itself to store the objects being represented in the ListView.

I realize this is a bad practice and tightly couples me to my presentation but I have trouble breaking free of it.

For example, I had a "Loot History" ListView that showed a list of items I had looted from an MMO. I was using the "Tag" property of each new ListView item to store the "Loot" object itself. So when I performed a delete or search among the loot I would search the tags of this listview.

What is the correct way to handle this situation?

Should my controller class be holding onto a List of my loot items, and it supplies this to my Form? Does the controller instantiate/own the form? If not, then who instantiates it?

Answer 1

If it works in a similar fashion to ASP.NET MVC, the answer to both of your questions is yes. The controller does hold on to a list of your items, and is responsible for instantiating the form.

If you want to be "correct," then check out how Koossery.MVCwin does it. Their statement about controllers:

Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn queries the database by using the values.

See also http://stackoverflow.com/questions/2406/looking-for-a-mvc-sample-for-winforms

Answer 2

First you need to decide which pattern your are going to use. MVC and MVP are slightly different. Have a look at Twisting the Triad for a good overview of the differences between them.

MVP is further divided into two variations: Supervising Presenter/Controller and Passive View. I tend to lean more toward Passive View but its not uncommon to find some Supervising Presenter/Controller mixed in my work when its appropriate. The reason I like Passive View is it moves as much code out of the UI as possible and into separate classes where it can be unit tested more easily. Passive View boils down to delegating data operations to the Presenter, which usually further delagates responsibility to domain objects. (not to be confused with C# delegates though this is one way to accomplish it)

Complex UI controls like ListView, DataGridView (and its predecessor DataGrid), and TreeView can be a hurdle for MVP Passive View especially (Supervising Presenter/Controller can usually use databinding to handle this).

• They display multiple distinct data values that may coincide with a the attributes of a single domain object or multiple domain objects.
• They rarely have fine grained events to handle updating individual data values.

Sometimes the best course of action is to find an alternative way to display the data. In some cases you can replace displaying multiple rows of related data with a Form and navigation controls. Other times its not so clear. In my own experiences I've successfully used the Tag property to hold references to the domain object represented by that List Item without the View knowing anything about the datatype it was storing. I accomplished this by passing the fields of the object to be displayed as system types and the object itself as a plain System.Object into an Add() method in the View.

Creating an untestable method in the View may seem counter to the whole point of MVP but it is really just a setter for multiple attributes. No data manipulation or calculations are occurring within the method. So there's little testing that could be done anyway.

Hope this helps.