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

[boB Stepp]

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

>> 1)  If I were to add code to filter user inputs, which file is the
>> logical place to place such code?  My current impression is that it
>> should go in the controller, but I could see it being in the view.
>> However, if I were to write a Validation class, I could see that as
>> having uses beyond checking just user input.
>
> Filtering user input is one type of validation (others include
> type and value checking) Usually the view (especially in a GUI)
> will control the type checking and in  some cases the value
> checking too (think calendar pickers). But the controller may
> also do some data adjustment (such as reformatting a date
> to suit a particular model). But mostly I expect the view
> to collect the correct data in terms of primitive type/value.

I perhaps see a general principle developing here:  Before passing
data elsewhere, the data should be validated and in a form suitable
for where it is being sent.  In my simple code example, I was trying
to do this:  Change the diameter, which was currently in a string
format, to float prior to sending it to the model.  And likewise,
changing diameter and circumference back to strings prior to being
sent to the view.

> An example where more complex validation might be required is
> where you want to validate a credit card or an account number.
> In that case the controller may call a business service before
> passing the validated details onto the appropriate model(s)
> to process.

By "business service" are you intending this to mean a totally
different application, or just a different model within the same
overall program?

> Models should usually expect to be given good data. In some
> cases you might want to do a belt n' braces data check in
> the model too, but mostly you assume your front end is
> catching the bad stuff (see file processing below).

I take it "braces" are what we call "suspenders" in the US?  So what
you are talking about is redundant validation?  When would this be
actually called for as it seems to contradict DRY principles?  The
only thing that is coming to my mind now is code for something where
failure is not an option and the source of the incoming data (Which
should be doing proper validation.) was coded by someone else.  If I
were coding both myself, then I would think that I should be able to
trust that I did the job correctly the first time!


>> 3)  If I were to add data files in place of (or in addition to) user
>> input, in which aspect of MVC would file I/O be handled?
>
> This is where things get interesting. When processing files the
> view/controller are only likely to be validating the filename and
> initiating the process. This means that there needs to be a model object
> somewhere that processes the file. But the content of the
> file is unsafe  so that model needs to do all the data
> validation that would normally be done in the view/controller.
>
> Its not unusual to have a dedicated model for such batch processing
> and it will then call the other model methods for each record processed,
> effectively becoming a controller of sorts. There may
> be opportunities for code reuse between the UI controller and
> the batch controller.

I guess what I am getting out of this discussion of MVC, is to not be
too rigid in my thinking, but try to decouple these three broad areas
of responsibility as much as is practical, so as to make the resulting
code more maintainable and scalable.  Is this the correct big picture
idea?

Thanks!

boB