[Tutor] Correct use of model-view-controller design pattern

[boB Stepp]

On Sun, May 29, 2016 at 9:10 AM, Alan Gauld via Tutor <tutor at python.org> wrote:
> On 29/05/16 05:33, boB Stepp wrote:

>> My current understanding is that the model contains program logic and
>> the data which the program logic manipulates.
>
> Correct, all the core entities which make up the program are represented
> by models. Most things stored in a database will
> have a corresponding model.

Ah, the first major misconception I have.  Until now I have been
thinking more in terms of a single overarching model.  From what you
say here (and elsewhere in your response) one might have a Customer
class/model, account class/model, etc., all of which map to "things
stored in a database".  Later you mention lower-level models, that I
presume are classes with lower level abstraction, and I suppose there
are higher level models which provide higher levels of abstraction,
hiding these lower level models/classes.  I chose a procedural
approach for my coding examples as that both comes most naturally in
my current stage of development and seemed simplest.  But it is
looking like MVC is most useful for an OOP approach to things.

>> The controller ties things together, refreshing the view appropriately,
>> receiving messages from the view when something there has
>> been changed by the user, interrogating the model when needed,
>> and receiving the model's results and refreshing the view
>> appropriately.
>
> The controller is where the confusion starts. Every implementation of
> the MVC pattern seems to change the way the controller is defined. You
> are broadly correct but some frameworks have a more view focussed
> interpretation, others more model focused. For example some GUI
> frameworks combine the view and controller concepts into a single Window
> object (the Delphi/VB/MFC/OWL Windows GUI frameworks all
> take that approach). The JSP type 1 framework is similar in that
> the JSP page does both roles. But in the JSP type 2 framework the
> controller is separated out into a distinct entity.

This is what motivated to post my questions.  I wanted an explanation
of why I could not get consistent explanations of MVC from the
different sources I read.  As usual I am thinking about things too
rigidly.

> What everybody(?!) seems to agree on is that events generated by the
> view are forwarded to a controller(*) which determines whether a model
> needs to be involved and is so what method of which model needs to
> be invoked.
>
> (*)If the controller is embedded in the view object then that is
> probably handled by an internal  superclass method of the framework
> and based on an event table (similar to Tkinter's binding mechanism)
>
> The model responds, but how the view is notified varies. In some cases
> the views register with models and the model automatically sends
> notification messages to all registered views (by-passing the
> controller). In other cases the model si8mply sends a reply to the
> controller that invoked it and the controller decides which views should
> be updated.

So there can be multiple controllers, too?  And I suppose at different
levels of abstraction to match the correspondingly available models at
different levels of abstraction?

> In practice it's hard to separate the controller and view
> entirely (which is why some frameworks combine them) but
> it should definitely be possible to separate the models
> from the more UI elements. What the controller does do
> is allow you to swap different views within a single UI.
> For example a list view, versus a form view versus a
> graphical view, all of the same object or set of objects.

I was intuitively suspecting this.

> But I'd probably not make the controller the main() function.
> Instead I'd have a separate main that constructed the objects.
> The controller then has a handle_event() type method that
> receives the event from the UI view.
>
> So you make the view responsible for initiating the
> event processing not the controller. The controller
> then becomes a fairly simple validate-dispatch mechanism.

This makes more sense to me.  When I was trying to imagine writing a
tkinter GUI to be the UI I could not visualize how to make the view
totally decoupled from the controller code.  Along with what you said
earlier this is all making a lot more sense now.

>> anything or missing any nuances?  Would this code scale upward as I
>> would hope?
>
> It would be a bit messy but could be adapted quite easily.
> For example instead of the if/elif chain use a dictionary
> for event dispatch.

What would be the "messy" issues?  I suspect these are the things that
I am not intuitively seeing and only realize retrospectively after I
get deep into coding.

Thanks!

boB