W typowych webowych frameworkach MVC stosuje się właśnie silniki szablonów, które generują jakby nie patrzeć frontend. Backendem są kontroler i model.
Chodziło mi o to, że "silniki szablonów, które generują frontend", jeśli odpalają się po stronie serwera, to są tak czy siak backendem, bo są na serwerze.
Dopiero w przeglądarce mogą stać się frontendem, ale wtedy już przestaną być silnikami szablonów tylko staną się kodem HTML (zakładam tutaj, że są to szablony tylko i wyłącznie po stronie serwera, a nie jakieś SPA). Subtelna różnica, ale jednak o ile nad silnikami szablonów masz kontrolę dopóki są po stronie backendu (i możesz je traktować jako "widok", taki frontend backendu, i np. karmić je danymi z bazy), to już jak są wygenerowane i przesłane do przeglądarki, to "widok" zaczyna żyć własnym życiem i można się komunikować z nim tylko przez internet.
(w ogóle może być tak, że MVC jest w zasadzie bardziej czymś w rodzaju fraktala. Z jednej strony można by powiedzieć, że Frontend to Widok, Backend to Model, a HTTP to Kontroler, ale jak wejdziemy głębiej, to zarówno Backend jak i Frontend można podzielić na Model/Widok/Kontroler - na frontendzie widokiem mógłby być np. React, modelem Redux a kontrolerem kod, który pomiędzy nimi pośredniczy. W samym komponencie React też masz z jednej strony widok - funkcję render, z drugiej strony masz model (czyli props i state) a z trzeciej strony masz funkcję obsługujące zdarzenia myszy choćby, czyli taki kontroler)
(czyli sam komponent Reactowy zawiera w sobie całe MVC a jednocześnie może być uznawany tylko za część V większej całości).
Wpychanie logiki biznesowej do kontrolera jest właśnie niezgodne z MVC. Jeśli ktoś tak robi, to popełnia błąd, i to co tworzy to nie jest MVC.
Zgadzam się z tym, problem w tym, że inni tego nie wiedzą. A o ile jeszcze w dyskusji można wyklaryfikować co dane pojęcia znaczą, to jak przejedziesz się po githubie, to już tak łatwo nie będzie, bo co framework, to różne definicje.
Nie chodzi mi o to, żeby wyznawać wolną amerykankę - sam czerpię informację na temat MVC z old schoolowych opisów do Smalltalka (języka, w którym w końcu MVC powstało), tylko raczej o to, że ta wolna amerykanka już istnieje.
Jakbym miał się kłócić o wszystkie pojęcia źle rozumiane, to by się okazało, że całe programowanie jest źle rozumiane:
- oprócz MVC źle rozumiane jest choćby OOP (dochodzi do absurdów, gdzie ludzie myślą, że OOP polega głównie na dziedziczeniu),
- programowanie funkcyjne jest mylone z proceduralnym albo jest traktowane na zasadzie że "są funkcje",
- Agile jest źle rozumiane i traktowane tylko jako robienie "sprintów" (cokolwiek ten sprint w praktyce znaczy. Czyli często po prostu tyle, że się planuje raz na tydzień i nazywa to edżajlem),
- Scrum jest rozumiany czasem głównie jako robienie spotkań na stojąco czy odprawianie innych dziwnych rytuałów towarzyskich (chociaż akurat Scrum to chyba sam w sobie jest taki porąbany)
- TDD jest źle rozumiane (gdzie unit jest rozumiany jako metoda i testy są 1:1 sprzężone z kodem produkcyjnym - co nieuniemożliwia potem jakikolwiek większy refaktor bez zmiany testów),
- DDD jest rozumiane czasem jako zestaw wzorców projektowych typu repo, encja, agregat itp., bez myślenia w ogóle o dziedzinie, którą się modeluje (wystarczy poczytać wątki na tym forum, gdzie ktoś włazi w DDD i tylko nad tym się zastanawia, w którym folderze który wzorzec wcisnąć, bo koniecznie chce użyć wzorca z książki).
- z kolei wzorce projektowe są nagminnie albo źle rozumiane, albo wciskane tam gdzie ich nie powinno być i nieużywane, tam gdzie pasują
Z drugiej strony warto oczywiście edukować ludzi (ew. wejść w polemikę tam, gdzie nie jest to oczywiste, gdzie może istnieć wiele poglądów na dany temat - też nie warto być dogmatykiem myślę, nie wszystko jest zawsze jasno zdefiniowane).
Ale to całe wykoślawianie idei mnie akurat bawi bo można zaskakiwać ludzi nietypowymi stwierdzeniami, które są prawdziwe (a przynajmniej: można je logicznie uzasadnić) a brzmią absurdalnie, bo ludzie się przyzwyczaili już do wykoślawionego rozumienia.