How to separate GUI and data

  • Thread starter Thread starter alan.chambers
  • Start date Start date
A

alan.chambers

I am new to C++/CLI. I want to do a very simple thing. In other C++
applications, my forms have always been 'context free' in the sense
that I pass them a temporary copy of the data for them to display and
munge about. If OK is pressed, the client of the form does something
with the temporary data. This approach is surely a commonplace, and I
have implemented it in real C++ something like this:

AddressData temp(original); // original could be of type AddressData,
perhaps an element in
// a vector of addresses .
AddressForm form;
if (form.Execute(temp))
{
// OK was pressed.
original = temp; // or whatever is approriate
}

bool Form::Execute(AddressData& data)
{
// populate controls from data.
bool result = ShowDialog() == DialogResult::OK;
if (result)
{
// populate data from controls.
}
}

Now, in .NET-land it seems that everything is a reference, including
so-called value types if they are added to an array. What is the usual
approach to data handling in .NET GUI design? I want to protect my data
from direct manipulation by forms, and to avoid the client of the form
knowing anything about it's implementation (e.g. all those public
controls used in MFC code).

Thanks.


UnicycleGuy
 
I would say that WM_COPYDATA is still a
good candidate for what you want to do.


Best regards.

____
Jean
 
(e-mail address removed) a écrit :
I am new to C++/CLI. I want to do a very simple thing. In other C++
applications, my forms have always been 'context free' in the sense
that I pass them a temporary copy of the data for them to display and
munge about. If OK is pressed, the client of the form does something
with the temporary data. This approach is surely a commonplace, and I
have implemented it in real C++ something like this:

AddressData temp(original); // original could be of type AddressData,
perhaps an element in
// a vector of addresses .
AddressForm form;
if (form.Execute(temp))
{
// OK was pressed.
original = temp; // or whatever is approriate
}

bool Form::Execute(AddressData& data)
{
// populate controls from data.
bool result = ShowDialog() == DialogResult::OK;
if (result)
{
// populate data from controls.
}
}

Now, in .NET-land it seems that everything is a reference, including
so-called value types if they are added to an array. What is the usual
approach to data handling in .NET GUI design? I want to protect my data
from direct manipulation by forms, and to avoid the client of the form
knowing anything about it's implementation (e.g. all those public
controls used in MFC code).
Click to expand...

Your "data" should be cloneable (ie, implement ICloneable)

Arnaud
MVP - VC
 
Matthew MacDonald addresses this topic in his book "Pro .NET 2.0
Windows Forms and Custom Controls in C#". He promotes the so-called
"Three Tier Design" guideline which consist in rigorously separating
the presentation, the program logic and the data.

Presentation Tier
(Windows, UI code)
/\
||
\/
Business Tier
(application logic)
/\
||
\/
Data Tier
(files, databases, networks etc.)

Here manipulation of data by forms i.e. in the form handlers is
considered evil.

"The form acts just as a switch board for all the controls it contains.
In other words, when you create the event handler for a button's
Click event, this event handler usually has two purposes:
· To forward the command to another object that can handle the task.
· To update the display based on any feedback that's returned."

By this in theory the classes of the data and presentation tier are
generic classes which you can reuse.

Look for a technique called "simple data binding with windows forms" -
this can help to seperate UI from data.

Semmel
 
Back
Top