Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Seperating Data & GUI, What pattern to use?

Seperating Data & GUI, What pattern to use?

Seperating Data & GUI, What pattern to use?

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.

RE: Seperating Data & GUI, What pattern to use?

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
Specialty Bakers, Inc.

RE: Seperating Data & GUI, What pattern to use?

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close