GUI in C#

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi there all,

I am currently working on a project in C# using .net as the IDE. Well the
real problem i am facing is that i have many many class files and i wan to
create a GUI to access and make use of these classes.

I notice that if i were to keep the main() method inside the form class
(assuming that this is the GUI) then i will have problems in the event that i
want to update or review my code and functions. I want to create an
independent GUI class that i can use and change as and when required. How do
i do that?

Also how do i make use of objects created inside the GUI class..say a
richTextBox inside another class.

example:
form class contains a richTextBox called rTxtBox
something class has a method that prints lines to rTxtBox...

however if i were to use
rTxtBox.Text = "blah blah blah";
inside something class it will be an error...

how do i work around this huh?

Thanks guys and sorry for the long post First time i am doing a GUI
involving more than 1 class in C#.

Thanks...hope to hear from u
Cheers,
Synapsy
 
Hello Synapsy,

Interesting post
I am currently working on a project in C# using .net as the IDE. Well the
real problem i am facing is that i have many many class files and i wan to
create a GUI to access and make use of these classes.

I notice that if i were to keep the main() method inside the form class
(assuming that this is the GUI) then i will have problems in the event that i
want to update or review my code and functions. I want to create an
independent GUI class that i can use and change as and when required. How do
i do that?
Click to expand...

My first question is: are you drawing the line in the right place?
In other words, in the traditional Model-View-Controller pattern, the act of
copying text into a control that displays it on the screen is part of the
View objects. What you describe is a layer, within the view components,
with the intent of making it easier to change the model or controller
components. However, I'd suggest that it would not make it easier... it
would simply move the work around.

Let's say you have a form that allows a user to enter 35 fields of data. In
a traditional model, the form would create business objects that have names
for each of the fields. By copying the values, the business object may
raise an exception due to validation failures. The user may click a Submit
button which would invoke a method on the business object to "save itself".
The business object calls data objects to apply changes to a database.

In your suggested model, the windows forms go through an extensive
declaration phase in order to bind each control to an object that has a
member that represents the displayable portion of the control. E.G.
DataForm.txPartNumber would be bound to a member of a ViewObject class:
MyViewObject.PartNumber. However, the View object would STILL have to turn
around and copy the value into a business object for validation and catch
the errors if validation fails and indicate that the business object should
persist its data.

Now, add a field because the business needs it. In the traditional model,
you add it to the GUI, and the business object, the DAL, and the database.
(Depending on how you coded your data objects, you may not have specific
fields, so you may not have to add it there). You wire up the forms to the
business object. You code up changes for retrieving and persisting the
data. You are largely done.

With your model, you would do ALL of the same steps as above, only you'd add
one more step: you'd have to add the new control to your initial binding
operation so that you can connect the GUI object to the View object.

So, you aren't defending your code from change with the model you suggest.
In fact, your code goes through slightly more churn when a change occurs.

Please forgive me if I don't go into technical details of how to wire up
this extra layer.
Also how do i make use of objects created inside the GUI class..say a
richTextBox inside another class.

example:
form class contains a richTextBox called rTxtBox
something class has a method that prints lines to rTxtBox...

however if i were to use
rTxtBox.Text = "blah blah blah";
inside something class it will be an error...

how do i work around this huh?

Thanks guys and sorry for the long post First time i am doing a GUI
involving more than 1 class in C#.

Thanks...hope to hear from u
Cheers,
Synapsy
Click to expand...

--
--- 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.
--
 
Thanks for the prompt reply Nick,

so based on what I gather, if i were to stick to a MVC design type does it
imply that i let the main() method of my system lie withing the GUI class???
Thus the GUI basically controls all the triggers to call up other methods
withing the underlying cliasses?

Thus what i did now was...i created 2 classes...1 using the windows form
designer and another class within the same name space. However, i realise
that i still cant call objcets in the form class from the new class. I think
i am missing some form of refernce to the form class. Attached is the sample
class files...

I am so sorry if i make no sense cause i am actually a student programming a
medium sized program for the first time using .net

Cheers
Synapsy
----------------------------------------------------------------------------------------------

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespaceTrial
{
/// <summary>
/// Summary description for Form1.
/// </summary>
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.TextBox txtBoxTest;
/// <summary>
/// Required designer variable.
/// </summary>
private System.ComponentModel.Container components = null;

public Form1()
{
//
// Required for Windows Form Designer support
//
InitializeComponent();

//
// TODO: Add any constructor code after InitializeComponent call
//
}

/// <summary>
/// Clean up any resources being used.
/// </summary>
protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}

#region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.txtBoxTest = new System.Windows.Forms.TextBox();
this.SuspendLayout();
//
// txtBoxTest
//
this.txtBoxTest.Location = new System.Drawing.Point(8, 8);
this.txtBoxTest.Name = "txtBoxTest";
this.txtBoxTest.TabIndex = 0;
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(115, 38);
this.Controls.Add(this.txtBoxTest);
this.Name = "Form1";
this.Text = "Form1";
this.ResumeLayout(false);

}
#endregion

/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.Run(new Form1());
}
}
}
-----------------------------------------------------------------------------------------------
using System;

namespace Trial
{
/// <summary>
/// Summary description for Class2.
/// </summary>
public class Class2
{
public Class2()
{
//
// TODO: Add constructor logic here
//
rTxtBox.Text = "123"; // this is an error
}
}
}
 
One problem with traditional MVC architecture is that it is ignorant of
event-driven programming. However, it is a useful paradigm for
partitioning, and I use it for that.

However, I would still state that I've seen nothing to lead me to believe
that your application should drive control away from the event-driven model.
(Which is essentially: "set it up and wait").

As for how to get your secondary class to call your form:

The main routine is a static method. It can occur anywhere. The windows
designer puts it into your first form, but you can move it without harm to
its own file if that makes you feel better.

Also, you can create the form object before you call Application Run.

[STAThread]
static void Main()
{

Form MyMainForm = new Form1();
// do other things
Application.Run(MyMainForm);

}

So, some of these other things can be:
Create your other class object
Store it into a singleton
Perhaps send references to the controls to the other class object...

Form MyMainForm = new Form1();
// do other things
myclass = new MyClass();
myclass.textcontrol1 = MyMainForm.Text1;
Application.Run(MyMainForm);


Now, when myclass wants to send some data to MyMainForm, it uses the
reference you already provided.

This is the layer of initialization I alluded to in my prior message
--
--- 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.
--
Synapsy said:
Thanks for the prompt reply Nick,

so based on what I gather, if i were to stick to a MVC design type does it
imply that i let the main() method of my system lie withing the GUI class???
Thus the GUI basically controls all the triggers to call up other methods
withing the underlying cliasses?

Thus what i did now was...i created 2 classes...1 using the windows form
designer and another class within the same name space. However, i realise
that i still cant call objcets in the form class from the new class. I think
i am missing some form of refernce to the form class. Attached is the sample
class files...

I am so sorry if i make no sense cause i am actually a student programming a
medium sized program for the first time using .net

Cheers
Synapsy
-------------------------------------------------------------------------- --------------------

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespaceTrial
{
/// <summary>
/// Summary description for Form1.
/// </summary>
public class Form1 : System.Windows.Forms.Form
{
private System.Windows.Forms.TextBox txtBoxTest;
/// <summary>
/// Required designer variable.
/// </summary>
private System.ComponentModel.Container components = null;

public Form1()
{
//
// Required for Windows Form Designer support
//
InitializeComponent();

//
// TODO: Add any constructor code after InitializeComponent call
//
}

/// <summary>
/// Clean up any resources being used.
/// </summary>
protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}

#region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.txtBoxTest = new System.Windows.Forms.TextBox();
this.SuspendLayout();
//
// txtBoxTest
//
this.txtBoxTest.Location = new System.Drawing.Point(8, 8);
this.txtBoxTest.Name = "txtBoxTest";
this.txtBoxTest.TabIndex = 0;
//
// Form1
//
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(115, 38);
this.Controls.Add(this.txtBoxTest);
this.Name = "Form1";
this.Text = "Form1";
this.ResumeLayout(false);

}
#endregion

/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.Run(new Form1());
}
}
}
-------------------------------------------------------------------------- ---------------------
using System;

namespace Trial
{
/// <summary>
/// Summary description for Class2.
/// </summary>
public class Class2
{
public Class2()
{
//
// TODO: Add constructor logic here
//
rTxtBox.Text = "123"; // this is an error
}
}
}
-------------------------------------------------------------------------- ---------------------


Nick Malik said:
Hello Synapsy,

Interesting post
How
do

My first question is: are you drawing the line in the right place?
In other words, in the traditional Model-View-Controller pattern, the act of
copying text into a control that displays it on the screen is part of the
View objects. What you describe is a layer, within the view components,
with the intent of making it easier to change the model or controller
components. However, I'd suggest that it would not make it easier... it
would simply move the work around.

Let's say you have a form that allows a user to enter 35 fields of data. In
a traditional model, the form would create business objects that have names
for each of the fields. By copying the values, the business object may
raise an exception due to validation failures. The user may click a Submit
button which would invoke a method on the business object to "save itself".
The business object calls data objects to apply changes to a database.

In your suggested model, the windows forms go through an extensive
declaration phase in order to bind each control to an object that has a
member that represents the displayable portion of the control. E.G.
DataForm.txPartNumber would be bound to a member of a ViewObject class:
MyViewObject.PartNumber. However, the View object would STILL have to turn
around and copy the value into a business object for validation and catch
the errors if validation fails and indicate that the business object should
persist its data.

Now, add a field because the business needs it. In the traditional model,
you add it to the GUI, and the business object, the DAL, and the database.
(Depending on how you coded your data objects, you may not have specific
fields, so you may not have to add it there). You wire up the forms to the
business object. You code up changes for retrieving and persisting the
data. You are largely done.

With your model, you would do ALL of the same steps as above, only you'd add
one more step: you'd have to add the new control to your initial binding
operation so that you can connect the GUI object to the View object.

So, you aren't defending your code from change with the model you suggest.
In fact, your code goes through slightly more churn when a change occurs.

Please forgive me if I don't go into technical details of how to wire up
this extra layer.


--
--- 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.
Click to expand...
Click to expand...
 
Nick Malik said:
One problem with traditional MVC architecture is that it is ignorant of
event-driven programming.
Click to expand...

That is a puzzling claim, Nick. The MVC design pattern does not
address how the view, controller or model portion is implemented.
Whether the controller or view determine what to do based on event
processing is a completely independent issue from the use of the MVC
pattern itself. So how can you claim such a problem?
However, it is a useful paradigm for partitioning, and I use it for that.
Click to expand...

I suppose one could say the same for most design patterns.
However, I would still state that I've seen nothing to lead me to believe
that your application should drive control away from the event-driven model.
(Which is essentially: "set it up and wait").
Click to expand...

Nothing I have seen would make me think using MVC would drive
away (or toward) an event-driven model.
 
I find your response curious, Larry. You speak as though there is only one
interpretation of MVC.

For example, in this article
http://ootips.org/mvc-pattern.html
The controller accepts the input, routes it through the model and brings it
back to the view. In rich client event driven programming, that means that
the controller code sits in the U/I layer, as does the view code... leaving
only the model code to exist anywhere else. No need for a data layer in
this model. This article, which is a summation of a chapter in a book on OO
programming, directly implies this.

On the other hand, this book, from Sun
http://java.sun.com/blueprints/guid...prise_applications_2e/web-tier/web-tier5.html
Describes the View as containing all logic for both user input and output,
while the Model maintains data and the Controller dispatches commands
between the two. (This is a better explaination, IMHO).

In the purist MVC structure, everything refers to everything. Problem is:
this doesn't compile very well. What really happens is that you factor up
to interfaces, and everyone is supposed to use interfaces to do the work.
This imposes a firm structure on the application that can really help
seperate the concerns, and make the application more adaptable to change.
The strength of MVC lies in the use of these interfaces.

The reason that I state that event driven programming is somewhat at odds
with MVC is that in event-driven development, events do not come FIRST to
the controller, even though the pattern is described that way. (For
example, here's a description of how the controller works: "Events typically
cause a controller to change a model, or view, or both. Whenever a
controller changes a model's data or properties, all dependent views are
automatically updated." from
http://www.enode.com/x/markup/tutorial/mvc.html )

There is an underlying naïveté in this description. There is an attempt to
ignore the fact that there is code that is modifying the view BEFORE the
controller is informed of the event. In modern GUI systems, this is nearly
always true. From the standpoint of the business, all images and characters
on the screen are part of the view. They care about where the characters
show up, what order tabs occur in, when validations occur, how many windows
appear... In the MVC pattern, this logic is part of the controller, yet in
modern GUI systems, 10-15% of this logic sits directly in the View classes
themselves, often configured directly into generic controls.

In practice, we end up passing commands and data modifications, often on a
field-by-field basis (rather than character-by-character, which is left to
the text control or drop-list control, etc). I've occasionally seen it done
on a screen-by-screen basis. We pass commands to the controller, which
interprets behavior, and, occasionally, calls the view back to get the data
that it will pass to the model to manage data manipulation and persistence.

One other thing that occurs in practice, but is often glossed over, is that
the controller owns and creates the view objects. So, the controller has to
be created first, and has to track and manage a set of these objects (tied
to the portion of the view that is displayed at the moment). It is the
complexity of these objects themselves that I am concerned about.

The traditional description of the view being automatically updated requires
that the controller pass a View object to the model to render itself with.

However, the view objects, if they are designed to be invoked by the model
objects directly, become very "command driven" because the model doesn't
know what portion of the view is actually visible (nor should it). This
ability to "automatically" update the view can, and often does, lead to
inordinately complicated logic in the view classes. This is where I think
the OP was heading. (I may have been mistaken... won't be the first time
:-).

That is why I use MVC for partitioning, but not for the dynamic structure
that I want my application to follow. I do not pass view objects to the
model to self-render. I tend to rely much more frequently on the layers
pattern. In this context, the model DOESN"T have any binding to the Views.
It isn't aware that the data is being viewed so it does not inform the view
that a data element has changed. In a sense, it is much more passive. The
Controller (now in the UI layer) will be informed of events, will interpret
them by using the contents of the controls themselves, will pass data into
the model, and will then call Render objects that know about the model.
These Render objects can extract the data that they need to copy information
back into the controls.

In other words, instead of having a single event start in the U/I, loop
through the controller, into the model, and directly back to the U/I, I'm
suggesting that your code is much simpler, and easier to maintain, if the
model doesn't know about its own display. Rather, the U/I knows what is
displayed in it, and can redraw itself by knowing about the model. This
means that an event begins in the U/I, is passed to the controller. The
controller gathers data from the controls, and either calls the view objects
themselves to effect structural changes (opening and closing windows,
manipulating the display), or calls the model to handle the data. The model
returns to the controller. The controller then calls the Render objects to
render the model data. The Model doesn't call either the controller or the
view in this layout and is effectively not bound to either.

Your coupling is reduced, since the model doesn't need to know about the
view. This isn't the MVC pattern at all... it is the Layers pattern. If
you reread my text above and read the term "Business Objects" every time I
said "Model", you will see how I got here.

What leads me to this spot is pragmatism. In a programming model where
events originate from U/I objects, and the U/I can enforce rules through
configuration, the notion of a view DRIVEN BY a model is out of touch with
current practice. It is expensive and unnecessary, IMHO. That is a
personal opinion, of course, but one that I am sure I share with others.

I hope that this clarifies my statements.

--
--- 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.
--
 
Nick Malik said:
I find your response curious, Larry. You speak as though there is only one
interpretation of MVC.
Click to expand...

No, I did not mean to imply such a proposition. And the difficulties
with narrow interpretations that you cover below have caused real
problems that I have observed in a few projects. I only meant to
decouple "event-driven programming" from the MVC concept.
For example, in this article
http://ootips.org/mvc-pattern.html
The controller accepts the input, routes it through the model and brings it
back to the view. In rich client event driven programming, that means that
the controller code sits in the U/I layer, as does the view code... leaving
only the model code to exist anywhere else. No need for a data layer in
this model. This article, which is a summation of a chapter in a book on
OO programming, directly implies this.
Click to expand...

Fusion of the view and controller is very common. They are often
so tightly coupled that treating them as separate modules is pretty
much a fiction, and some people have the good sense to not try to
maintain such a fiction. (The MFC design comes to mind.)

However, just because a controller sits in the U/I layer does not
necessarily make it inseparable from the view module(s). To be
sure, a controller accepting user input interactively must be in
the U/I layer, at least partially, and likely shares some or most
presentation with one (or more) view(s) dedicated to U/I.
On the other hand, this book, from Sun
http://java.sun.com/blueprints/guid...prise_applications_2e/web-tier/web-tier5.html
Describes the View as containing all logic for both user input and output,
while the Model maintains data and the Controller dispatches commands
between the two. (This is a better explaination, IMHO).
Click to expand...

That sounds like one of those fictions to me. Somebody has
determined, in advance, that there will be M, V, and C, and
after some puzzlement, "View" becomes "what can be seen",
"Controller" becomes "anything controlling the model", and
"Model" becomes the data layer.
In the purist MVC structure, everything refers to everything. Problem is:
this doesn't compile very well. What really happens is that you factor up
to interfaces, and everyone is supposed to use interfaces to do the work.
This imposes a firm structure on the application that can really help
seperate the concerns, and make the application more adaptable to change.
The strength of MVC lies in the use of these interfaces.
Click to expand...

I pretty much agree with this assessment, except for the slight
exaggeration in "everything refers to everything". The problem
with coupling is very real, and separating those concerns, even
when difficult in the face of much coupling, can yield benefits.
The reason that I state that event driven programming is somewhat at odds
with MVC is that in event-driven development, events do not come FIRST to
the controller, even though the pattern is described that way. (For
example, here's a description of how the controller works: "Events typically
cause a controller to change a model, or view, or both. Whenever a
controller changes a model's data or properties, all dependent views are
automatically updated." from
http://www.enode.com/x/markup/tutorial/mvc.html )
Click to expand...

Here is where I think you have gone astray.

First, an example of a typical flow-of-control does not constrain
what can be properly considered MVC.

Second, there is no reason to identify the initial handler of
events as part of the controller or to claim that, because
that initial handler cannot be in the controller, event-driven
programming is inconsistent with MVC.

I believe it is a mistake to consider event input to be part
of "the view". The "view" concept is much more abstract,
better thought of as a projection of some subset of the
model's data with whatever transformation is appropriate
for the intended target and medium.
There is an underlying naïveté in this description. There is an attempt to
ignore the fact that there is code that is modifying the view BEFORE the
controller is informed of the event. In modern GUI systems, this is nearly
always true. From the standpoint of the business, all images and characters
on the screen are part of the view. They care about where the characters
show up, what order tabs occur in, when validations occur, how many windows
appear... In the MVC pattern, this logic is part of the controller, yet in
modern GUI systems, 10-15% of this logic sits directly in the View classes
themselves, often configured directly into generic controls.
Click to expand...

Here, I believe, you are confounding what can be seen on
the screen with "the view". That is indeed a "view" in the
common sense of the word. But it is not the "View" in
"MVC" and it is not the abstract view I allude to above.
In practice, we end up passing commands and data modifications, often on a
field-by-field basis (rather than character-by-character, which is left to
the text control or drop-list control, etc). I've occasionally seen it done
on a screen-by-screen basis. We pass commands to the controller, which
interprets behavior, and, occasionally, calls the view back to get the data
that it will pass to the model to manage data manipulation and persistence.
Click to expand...

Of course the controller does not deal in characters. Collecting
input into meaningful chunks is not the controller's job, else it
could never be shared between, say, interactive user input and
a script-driven input source. I suspect that confounding this low-
level input collection with the vague notion "Controller handles
'telling model what to do'." is what leads to difficulty with MVC.
One other thing that occurs in practice, but is often glossed over, is that
the controller owns and creates the view objects. So, the controller has to
be created first, and has to track and manage a set of these objects (tied
to the portion of the view that is displayed at the moment). It is the
complexity of these objects themselves that I am concerned about.

The traditional description of the view being automatically updated requires
that the controller pass a View object to the model to render itself with.
Click to expand...

That is a role for the controller that I have not seen (or do not
remember from my study of design patterns). I believe that role
is better considered to be part of a specific I/O interface. It is
necessary for interactive user interfaces. It is normally not needed
for script driven input. For a web interface, it will likely be done
much differently than for a traditional GUI. A SOAP interface
will do it yet another way.
However, the view objects, if they are designed to be invoked by the model
objects directly, become very "command driven" because the model doesn't
know what portion of the view is actually visible (nor should it). This
ability to "automatically" update the view can, and often does, lead to
inordinately complicated logic in the view classes. This is where I think
the OP was heading. (I may have been mistaken... won't be the first time
:-).

That is why I use MVC for partitioning, but not for the dynamic structure
that I want my application to follow. I do not pass view objects to the
model to self-render. I tend to rely much more frequently on the layers
pattern. In this context, the model DOESN"T have any binding to the Views.
It isn't aware that the data is being viewed so it does not inform the view
that a data element has changed. In a sense, it is much more passive. The
Controller (now in the UI layer) will be informed of events, will interpret
them by using the contents of the controls themselves, will pass data into
the model, and will then call Render objects that know about the model.
These Render objects can extract the data that they need to copy information
back into the controls.

In other words, instead of having a single event start in the U/I, loop
through the controller, into the model, and directly back to the U/I, I'm
suggesting that your code is much simpler, and easier to maintain, if the
model doesn't know about its own display. Rather, the U/I knows what is
displayed in it, and can redraw itself by knowing about the model. This
means that an event begins in the U/I, is passed to the controller. The
controller gathers data from the controls, and either calls the view objects
themselves to effect structural changes (opening and closing windows,
manipulating the display), or calls the model to handle the data. The model
returns to the controller. The controller then calls the Render objects to
render the model data. The Model doesn't call either the controller or the
view in this layout and is effectively not bound to either.

Your coupling is reduced, since the model doesn't need to know about the
view. This isn't the MVC pattern at all... it is the Layers pattern. If
you reread my text above and read the term "Business Objects" every time I
said "Model", you will see how I got here.

What leads me to this spot is pragmatism. In a programming model where
events originate from U/I objects, and the U/I can enforce rules through
configuration, the notion of a view DRIVEN BY a model is out of touch with
current practice. It is expensive and unnecessary, IMHO. That is a
personal opinion, of course, but one that I am sure I share with others.

I hope that this clarifies my statements.
Click to expand...

It certainly shows what led to them.

Depending on what an application is supposed to do, (initially
and as it evolves), the MVC pattern may well be more trouble
than it is worth, largely for the reasons you touch upon. It can
be a lot of work to get the view and controller separated; work
which may be wasted if there will be only one controller that is
intimately coupled with a few views.

However, that said, if the OP has good reason to use the MVC
pattern, the fact that some of VC part will be implemented with
an event-driven design does not preclude going that way. We
can agree, I think, that a sensible MVC partitioning is harder
for a traditional (event-driven) GUI than some other schemes.
....
 
Back
Top