Hi,

Peter Duffy <peter@???> writes:

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

I first ran into MVC with Smalltalk and Qt (around 1.33 ;-), sometime in
the mid 1990's. I've applied the rules-of-thumb doing GUI work with
GTK+ (and gtkmm) and again with Node.js and Rails web application work.
What you say about trying to "keep everything within some kind of
reasonable and supportable structure, and keep myself from going insane"
is spot on.

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

That jives quite neatly with the "definitions" in the first section of
that Wikipedia article on MVC that I mentioned in another post in this
thread.

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

Rails also has these library and helper notions. Very nice to give
developers the freedom to move outside the framework's paradigm when
they feel the need to. Straight-jacketing development and "my way or
the highway" frameworks (systemd anyone ;-) are counterproductive.

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

Same here.

> [...]
> Hope that helps . . . ?

Me too ;-)

> 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

--
Olaf Meeuwissen