I too have never found any generally-accepted and rigorous definitions
of Model, View and Controller (or any of the other MVC jargon).
However, as someone who's using it (literally developing in
CodeIgniter, in a bunch of terminal windows open at the moment), I
could give the rules-of-thumb which I use to try to keep everything
within some kind of reasonable and supportable structure, and myself
from going insane. So here goes.

Anything which accesses external data goes in a Model. For example, one
of the big changes for the site which I'm redeveloping is the
introduction of a mysql database, and all the SQL queries go into a
Model.

Anything which generates HTML goes into a View. (If I find that I'm
writing a lot of PHP code, I consider putting some of it into a Library
or Helper.)

Anything which is called by the triggering of a Route, which co-
ordinates Models and Views, and generally puts things together goes
into a Controller.

Anything which doesn't fit reasonably neatly and cleanly into one of
those categories goes into a Library, a Helper or maybe something else.

Re. multiple instances of Models and Views - yes, any number of them:
in CodeIgniter (probably in all other MVC frameworks), each one is just
a class, extending the base Model/View/Controller classes provided by
the framework.

The above ***seems*** to work, at least for me. (A few weeks ago, I
needed an event calendar: in CodeIgniter 3, there was a built-in
calendar library, but in v4, it's been removed for some baffling
reason. So I hunted about until I found one which had been written for
Wordpress, so it was monolithic and had lots of WP dependencies. Using
the above principles, I was able to rewrite it for the MVC framework
without too much trouble.) In many ways, for me, the great thing about
it all is the lack of hard definitions, and the consequent flexibility:
just means exerting some self-discipline to keep it in order. (As
specialisation increases, flexibility decreases. The main problem with
CMS systems is that when one hits something that the current one can't
do, one really has no option but to throw it out and try something
else. I originally tried developing the site on which I'm working in
Drupal: I needed to fit in an extra database, and Drupal 6 supported
that. Then I upgraded to Drupal 7 and found that the extra database
module hadn't been included in the new version. At that point, Drupal
went in the bin, and I started looking at MVC frameworks.)

(The perennial problem with web development, for me, is CSS. The
complexity of v3 - especially the grid module - is just mind-boggling.
(Having said that - grid layout is a massive improvement on anything
preceding it.) Then there's the requirement these days to write
"responsive" sites - starting with something that works and looks good
on a mobile phone, and then using "progressive enhancement" to work up
towards big (normal?) displays. It's just so counter-intuitive.)

Hope that helps . . . ?


On Sun, 2024-08-18 at 07:46 -0400, Steve Litt wrote:
> Olaf Meeuwissen via Dng said on Sun, 18 Aug 2024 17:56:52 +0900
>
> > While I agree that view and controller are typically highly
> > coupled, it
> > does make sense to separate them as much as possible.
> >
> > An application may need to represent information in a number of
> > formats, e.g. PDF, HTML, JSON, YAML and text/plain.  You probably
> > want
> > to separate out the nitty gritty formatting in a different
> > implementatioin for each with a common base View.  That way, the
> > common base is the only thing that couples tightly with the
> > Controller.
> >
> > Hope this helps,
>
> Hi Olaf,
>
> I wish it helped, but it doesn't help me. Questions:
>
> 1. What is the definition of a Model?
>
> 2. What is the definition of a View?
>
> 3. What is the definition of a Controller?
>
> 4. Can/should there be multiple instances of Model and/or View and/or
>    Controller?
>
> 5. How can one know for sure whether a piece of code should go in the
>    Model, the View, or the Controller? As I look at MVC examples on
> the
>    Internet, I see quite a bit of variation as to where pieces of
> code
>    should be placed.
>
> I see all sorts of contradictory answers to the preceding questions
> all
> over the Internet. And on the Internet I see a lot of MVC volleyball
> code leading to design difficulty, debugging difficulty, maintenance
> difficulty, and feedback loops.
>
> SteveT
>
> Steve Litt
>
> http://444domains.com
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng