Seperating Data & GUI, What pattern to use?

[NeilTrain]

So I have a large set of data objects, arranged Hierarchically, i.e.:

Project Node
- High Level Node
- Mid Level Node
- High Level Node
- Mid Level Node
- Low Level Node
- Mid Level Node
- Low Level Node
- More Data
- Low Level Node

And I also have GUI data that gets included with some nodes.
The data isnt always displayed in the same structure as the data (i.e. Project node is a given, therefore isnt displayed, and low level data may be ommitted as well)

Since my data objects are used in multiple applications (some with differing gui's, some with no GUI at all)

Whats the best way to keep Data and GUI data seperate but synched when a gui is used?

GUI nodes may need to be dependent on the actual data, but the data should never be dependent on anything in the GUI.

I'm sure there is a pattern for this problem but I am not exactly sure which one and how to apply it.

I was thinking of making an Interface called iDecorator, which would be implemented in the GUI, and each data node would have a "Decorator" member that is just a reference to the GUI counterpart of that data node.

The GUI data may need to be stored along with the hard data, for example, in some applications, the user may be able to "collapse" a node, to hide a large number of child nodes. This data may only apply to this application, but should be stored along with the rest of the project (or am i wrong here too?)

Any thoughts, ideas, or can someone at least point me to the correct pattern to look into?

Thanks a lot in advance.

 

[jmeckley]

I'm having a difficult time following. could you make this more concrete?

Since my data objects are used in multiple applications (some with differing gui's, some with no GUI at all)

Are you trying to build a generic framework? Have you built this functionality many times in previous applications?
If, not I would only focus on the current application. Only add functionality as necessary.
If you have then pull from the previous projects on what functionality is required. Again only build what you need right now, not what you may need in the future.

There are a couple patterns that come to mind.
Composite pattern for the structure of your data.
Model View Presenter/Controller for GUI/Data interaction.
But these are just buzz words without a context as to what problem they are solving for you.

At it's core you want to apply SOLID principles as much as possible patterns and methodologies are a result of that.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[NeilTrain]

I've already developed one desktop app, which had its data objects in a DLL (with GUI data attached, because I needed a place to put it)

That same DLL was used in an XML webservice which used the same data objects (ignoring any GUI specific data) and all worked fine.

But now we are building two new desktop apps, (and soon multiple web apps) both with different gui's (and different from the original app) But all use the same underlying data. Problem is all the extra peices of gui information in these objects is getting very messy.