Re: GUI in C#

From: Larry Brasfield (donotspam_larry_brasfield_at_hotmail.com)
Date: 01/31/05 

Date: Mon, 31 Jan 2005 11:36:12 -0800

"Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in
 message news:bOydnZ5g2J72wWPcRVn-sg@comcast.com...
>I find your response curious, Larry. You speak as though there is only one
> interpretation of MVC.

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.

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/guidelines/designing_enterprise_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).

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.

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 )

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.

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.

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.

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.

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.

> "Larry Brasfield" <donotspam_larry_brasfield@hotmail.com> wrote in message
> news:ejPrNxuBFHA.936@TK2MSFTNGP12.phx.gbl...
>> "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
> news:5LGdndQ-IrcZZWHcRVn-3Q@comcast.com...
>> > One problem with traditional MVC architecture is that it is ignorant of
>> > event-driven programming.
>>
>> 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?
... 

-- 
--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.

Relevant Pages

  • Re: MVC & MVP
    ... how MVC and MVP are implemented in .NET (MVC Framework versus Web Client ... so there are some bits that may not apply to a generic MVC vs. MVP ... view and controller (piece that marries the two. ... do not need the extra decoupling of UI from presenter, the MVC pattern will ...
    (microsoft.public.dotnet.framework.aspnet)
  • A few questions regarding MVC
    ... I have a few questions regarding the MVC pattern. ... controller can take the appropriate actions. ... Strategy is an object that represents an algorithm. ...
    (comp.object)
  • Re: A few questions regarding MVC
    ... circa 1970 version or some modern variation? ... Using the classic MVC archticture as a guide to understanding modern ... controller can take the appropriate actions. ... views are observers <- model ...
    (comp.object)
  • Re: ttk::checkbutton - I think, its a bug
    ... If your implementation of MVC is a View that directly updates the Model, ... So you don't consider the bindings, and the code behind the bindings, ... to be considered a controller? ... what happens if you have a widget for the same data on several ...
    (comp.lang.tcl)
  • Re: MVC in C++
    ... Things are now flowing more along the classic MVC lines. ... > struct Observable ... > string version; ... In that case the Controller would trigger a model update *and it* could ...
    (comp.object)
Loading