Help on design decision with Tree structure data

[kurotsuke]

I have some data organized in a tree structure saved in an XML file
and I want to display it in a TreeView control (the XtraTreeview of
DevExpress).

Each data item I would like to store in a class so that I can attach
to it some logic (for example to each data is associated an Execute
method).

I wonder what is the best solution: subclass the TreeView Node and
extend it adding all the logic I need or create a completely detached
tree structure that contains my data and then link it somehow to the
TreeNode component (probably this way is nicer since I don't match and
mix business logic with the interface).

One thing to notice is that the data will change (the user can modify
it) so I'll have to take care of updating the data structure.

Thanks a lot for any suggestion.
Andrea

 

[Cor Ligthert]

Kurotsuke,

In my opinion is the xmlnodereader a solution for your problem

http://msdn.microsoft.com/library/d...ml/cpconreadingnodetreeswithxmlnodereader.asp

I hope this helps?

Cor

 

[kurotsuke]

Kurotsuke,

In my opinion is the xmlnodereader a solution for your problem

http://msdn.microsoft.com/library/d...ml/cpconreadingnodetreeswithxmlnodereader.asp

I hope this helps?

Cor

Thanks. So what do you suggest? To store my data in the xmlNodeReader
structure? How can I add my own business logic to it? Do I need to
subclass it?
Thanks again for your help.

 

[Cor Ligthert]

Kurotsuke,

I got the idea that you wrote I have my data organized in a tree structure
saved in an XML file, that gave me the idea that it is not a dataset with
your business logic in it.

However even when then and it is for a Treeview control as you wrote, than
can the xmlnodereader do a very good job because the treeview holds normaly
only one infomationpart of a node.

Cor

 

[William Stacey [MVP]]

I would subclass the TreeNodes per your node type. No expert here, but as
your treeview and business logic get more complex, binding that logic inside
the treeview nodes gets complex and intertwined with your gui logic. My
solution was to create my own tree using treeview as a guide and had all
strong typing of nodes and add, delete, etc methods. That way I had clear
separation between gui and business logic. The gui treenodes would handle
the icons, context menus, and general gui behavior and call the "business
tree" for adds, etc. (which may also mean network calls.) The downside is
you basically have two memory copies of much of the data depending how you
fill your treeview (lazy or not). The up side is you can now easily use
another tree control, console app, or other and keep your business tree with
all the logic the same as it has no gui knowlege at all. You can use the
default TreeView without a gui (i.e. a console app), but there was some
things I did not like about that solution either. You should be able to
fill both trees with one method using your xml data or db, etc. Maybe
others have a better pattern. Cheers.

 

[Nick Malik [Microsoft]]

Hello Andrea,

I would recommend that you keep the data in a seperate structure from the
treeview for the reason that you cited: seperation of data from its
representation.

So how would you make it easy to display in a treeview? Use the visitor
pattern. http://www.dofactory.com/Patterns/PatternVisitor.aspx

As for creating the tree structure itself, if you have a schema for the XML,
you can use the XSD tool (comes with the .NET SDK, a free download) to
create code that matches the XML structure. Then you can use the XML
deserialization methods to read the entire file directly in the structure in
a single call.

Use the XSD tool only once: to create the initial code. Then pull it apart
and add methods and properties to the classes it creates. You have to
accept some limitations on the way you define the classes if you do this
though. The code that XSD.EXE emits will make all of your properties as
public variables, not as real properties. If you want to convert it, you
will need to dig in to learn the correct attributes to drive the
deserialization process.

I hope all this helps.

--- Nick

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[kurotsuke]

So, I've figured out that the best choice is to separate the UI from
the logic so I should create a tree structure myself for my nodes and
then synchronize it to the UI. How do you suggest to solve this part,
that is how to synchronize the UI with the data structure? Should I
associate every node of the TreeView to node of my structure (e.g.
using the Tag property) or is there a better solution?
Thanks.

 

[grant]

Hi Andrea,

Separating the UI and business logic is a good idea. This is what
data binding does for you with other standard controls (eg ListBox).
It allows you to work with the underlying domain objects and lets the
data binding take care of the mapping between the domain object
properties and UI properties. Unfortunately the standard TreeView
control does not support databinding.

Using the Tag to store a reference to the underlying domain object is
probably the simplest solution, but it will mean that you have a lot of
code that actually builds the TreeNodes and sets their properties
embedded in your form. This may be OK if you only need the tree in
one part of your application. A neater solution would be to derive a
new class(es) from TreeNode that take your domain objects as an
argument in the constructor. The derived class(es) would set the
TreeNode UI properties based on the domain object properties. This
provides a nice encapsuation of all the UI mapping logic.

If you are open to a commercial solution then our Virtual Tree control
provides a very good data binding solution. It can bind to your
existing business data model and handle automatically the
synchronization issues. You can download a fully functional trial
version at:

http://www.infralution.com/products.html

Most other tree data binding solutions that I have seen require your
data to be in a flat, homogeneous format (you supply a single list
containing all the domain objects and each domain object must support a
standard property which designates its parent in the hierarchy). This
forces you to change your data model to fit the UI and is also very
inefficient with large data sources. VirtualTree is designed from the
ground up to be data bound and can bind to any data model.
Regards
Grant Frisken
Infralution