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

[Alan Gauld]

On 31/05/16 02:16, boB Stepp wrote:

> 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.  

Correct.

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

Either. It could even be a web service provided by a different
organisation altogether. This is quite common for credit checks
and the like. (Although a credit check would almost certainly
be done by a model rather than a controller... That falls into
business logic territory not presentation.)

> I take it "braces" are what we call "suspenders" in the US?  

I believe so. Suspenders in the UK are used to hold up your socks :-)

> you are talking about is redundant validation?  When would this be
> actually called for as it seems to contradict DRY principles?  

Correct. The file handling example is a case where it might be valid
since the model may use the same method to process a line from a file as
a record from the UI. However some OOP practitioners like to build some
validation into models anyway because models are often reusable in non
UI context - eg batch processing jobs - where there is no front end
validation.

Another case is where an organisation publishes its model API behind a
web service. Can you trust your web clients to validate? Maybe not. So
you either validate in the web service code or in the model.

Yet another case is where you handle mission critical shared data. If
you are writing that data into a central database shared with multiple
applications you need to be sure you don't corrupt it so you may add
some validation, just in case...

> 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!

Absolutely right.

> 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?

Yes, although for any given implementation you should decide the
responsibilities and stick to them. I'm currently doing a lot of Java
coding and the Java Swing UI framework has a very specific and rigid
take on MVC and you have to use that definition of the UI simply won't
work! So the framework you choose will often determine how you use MVC.
But in the bigger picture it is a set of principles.

MVC is one specific version of the more general programming rule to
separate presentation from business logic.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos