views:

761

answers:

5

I have a sort of tree structure that represent a hierarchy of layers in a map, divided by types of layers and categories. Each node can be a different class for different types of layers (but all nodes implement a common interface).

I need to convert that class to an ASP.NET TreeView control. Each node in the input tree is a node in the output tree, with properties set that are dependant on the type of the node. I don't want the input tree classes to know the UI classes, so I can't write a "ToTreeViewNode()" method in them. There are currently 4 types of concrete node classes, 2 of them are composite (contain child-nodes) and 2 of them are leaves. This might change in the future.

It feels like there is a design pattern here itching to be used, can you help me find what it is?

A: 

It sure sounds to me like you want to use Model-View-Controller here. Your tree map structure is probably the Model, the View is the TreeView control - you probably need to add a Controller class of some kind to manage the interaction between the two.

1800 INFORMATION
Yes, but I'm talking about the actual act of traversing the tree. What I'm trying to avoid is a lot ["if (node is GroupLayerNode) do this, else do that"].
Doron Yaacoby
+2  A: 

A Visitor perhaps, to walk input tree and build corresponding UI tree?

Constantin
This has the disadvantage of having to rebuild the tree everytime the original model changes in structure
Harald Scheirich
+1  A: 

My .NET is a little bit rusty, but what you could do is create a separate subclass of TreeNodeCollection and possibly TreeNode, give them access to your structure an assign your TreeNodeCollection to the Nodes property of the TreeViewControl.

The TreeNodeCollection wrapper will convert your structure into a TreeViewControl structure. The TreeNode class will probably contain a reference to your own nodes, but will convert your nodes into TreeNodes.

In other words by implementing those two interfaces you adapt your model's interface to the one the TreeViewControl uses,

If you use the Visitor pattern to create a parallel structure you would have to run it every time there is a change. Or you would still have to wrap your node with the TreeNode interface.

See Adapter pattern

Harald Scheirich
A: 

Hope to have your question right:

From the "O'Reilly - Designing Interfaces Patterns for Effective Iteration Design"

You got these two patterns that generally get associated with trees:

  • "Cascading Lists"
  • "Treemap"

The chapter 6 of this book as around twelve design paterns patterns to be used to show complex data.

I didn't found any links to these patterns so i guess you'll need to check the book at the local library. I found this webpage which might have some paterns to help you but I've checked and it doesn't include those two, or the ones from chapter 6. http://www.welie.com/patterns/

fmsf
+1  A: 

I am not sure what you are trying to achieve, but (as I understand it) I think that if you gonna use both:

  1. Composite - for the nodes (tree)
  2. Strategy - for the implementation of the Drawing "algotithm"

so you will have:

public class Node
{
   public IDraw genericDrawing;
   public Node[] Childs;
   public Node() { //init you genericDrawinf }
   public void Draw() 
   {
      genericDrawing.Draw(this);
      foreach (Node child in Childs)
      {
         child.Draw();
      }
   }
}

public interface IDraw
{
    void Draw(Node node);
}
public class SimpleDraw : IDraw
{
    public void Draw(Node node)
    {
       // code your stuf in here.
    }
}

the great thing is:

  1. you don't need recursive drawing each one drawing itself
  2. your drawing strategy can change during runtime or during an instance of an object
  3. you can scale up each one of you class hierarchy with no dependency in the other structure.
  4. think of it like the controls in your Web forms
  5. moreover, each object is (SRP) Single Responsibility Principle

Enjoy.

rabashani