views:

303

answers:

3

I have some hierarchical data in a Winforms TreeView control and I need to expose it as a property so my presenter can synchronize changes to it. Just to be clear, I'm using the Passive View pattern. With most WinForm controls this is a no-brainer. The controls themselves expose their data as a system type which can easily be passed along to the presenter. TreeViews, because of their complexity don't map easily to a system type. I looked for a framework collection type but tree's seem to have been overlooked. (Microsoft appears to use tree structures underneith the hood for several higher level classes but chose not to create a family of general purpose Tree classes.)

In any case the data I'm trying to expose is never more than two nodes deep so I'm not even sure I'm going to continue using TreeView. All the more reason to avoid tying the presenter to a TreeNodeCollection.

I've already come up with a few ideas but I just wanted to bounce them off the SO community:

  • Expose the tree as a collection of collections... say a dictionary of lists.
  • Create a custom tree structure, introducing a dependency into the view in the process.

The top-level nodes will average 5-10 entries while their child nodes could theoretically hit counts as high as 50 but in practice won't go over 3 or 4.

Any suggestions?

A: 

Here are links to three free .NET libraries that contain tree collection implementations:

I don't have experience with any of them.

Jamie Ide
Thanks. A third party tree implementation is one alternative. Though it would still introduce an extra dependency into the view.
codeelegance
A: 

If this is a performance dependent app, i'd advise agianst the use of tree based collections

Jason Watts
The data being presented in the tree view isn't updated very often so performance isn't an issue. I'm more concerned with a clean separation of the view and presenter.
codeelegance
A: 

I think you have to think in the opposite direction: how should presenter expose a hierarchical structure to a view. And you should think about the view in abstract terms and not concentrate too much on the concrete implementation (TreeView in your case). Typically when you start implementing stuff using the MVP pattern, you will start writing presenter logic, at the same time defining the view interface. Ideally you would do this using TDD and a mock implementation of the view. Only then you would implement a concrete view (Windows form or a control).

So: you have to create a model which will then be passed to the view. I would suggest implementing a custom hierarchical structure (see Composite pattern).

In your case the implementation of the view could use the Tag property of the TreeViewNode to map between TreeView's nodes and the elements in your model.

Igor Brejc
I am using TDD and mocks to drive my implementation. I have a blank form implementing my view interface so each time I add to the interface I'm adding to the form implementing it as well. In this case I already had the idea for using a tree view but couldn't figure out how to use it without either contaminating the view or the presenter with needless dependencies. I'm leaning toward a simplified view interface even at the expense of a more complex view implementation. I can always refactor later.
codeelegance