Hi Steve, list,

# I've restored the context that Steve left out.

Steve Litt <slitt@???> writes:
> Olaf Meeuwissen via Dng said on Sun, 18 Aug 2024 17:56:52 +0900
>> Hendrik Boom <hendrik@???> writes:
>>> On Thu, Aug 15, 2024 at 03:37:18PM -0400, Steve Litt wrote:
>>>> Andrzej Peszynski said on Wed, 14 Aug 2024 23:54:54 +0200
>>>>
>>>>> 3. Web/DB applications, simplified abstractions, MVC - PHP and JS
>>>>> family.
>>>>
>>>> Am I the only one who things MVC is absolute bullshit, where everyone
>>>> has different definitions of it and everyone cheats on the definition?
>>>
>>> Separating the model from the VC makes sense.
>>> Separating the viesfromthe controller makes no sense.
>>
>> 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.

I was merely replying to Hendrik's statement that separating view and
controller makes no sense. I did not comment on MVC in general but ...

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

Please read the Wikipedia article on MVC at

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

The "definitions" in the introductory section work for me. In that they
give me enough to base design decisions on so that I get things mostly
right the first time around much of the time.

Note that MVC has been around for a while, since around 1980, and has
given rise to a fair number of offshoots that split responsibilities
slightly differently and use other terminology.

Feel free to use whatever fits your problem at hand. Just like you'd
pick a suitable programming language for whatever you are trying to get
done. In both cases, current skill set is a big factor of course.

> 4. Can/should there be multiple instances of Model and/or View and/or
>    Controller?

Yes. Multiple Model classes, multiple View classes, multiple Controller
classes. How many of each you need depends on the application (and your
design).

Having multiple View classes for the same Model class is perfectly
okay. Ditto for Controller classes.

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

You cannot. Not in general, not for sure.
But you can become quite confident that you're doing things right most
of the time. And if you find out later that you got it wrong you can
always refactor :-)

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

If your "volleyball" refers to going back and forth between objects
and/or classes to get stuff done, then I agree but think that comes
about as a result of object orientation more than as a result of MVC
per se. Heck, it might even be caused by the "Do only one thing and
do it well" way of thinking ;-)

Another factor is that technical debt is not removed regularly or even
at all. Muddling on based on code that is already muddling on is just
asking for trouble. You cannot blame MVC, or any other design pattern
for that matter, for that.

Hope that helps,
--
Olaf Meeuwissen