Django kontra kontroler widoku modelu [zamknięty]

Czy ktoś może mi wyjaśnić, gdzie występują różnice między Django a wzorcem kontrolera widoku modelu?

Czego możemy się spodziewać pod względem funkcjonalnym po tych różnicach - tj. Co działa inaczej w porównaniu na przykład z Django do Ruby on Rails?

Zgodnie z Django Book , Django na tyle ściśle podąża za wzorcem MVC, że można go nazwać frameworkiem MVC.

Django jest określane jako framework MTV, ponieważ kontroler jest obsługiwany przez samą strukturę, a większość emocji dzieje się w modelach, szablonach i widokach.

Możesz przeczytać więcej o MTV / MVC tutaj:

Wzorzec programistyczny MTV (lub MVC)

Jeśli znasz inne frameworki internetowe MVC, takie jak Ruby on Rails, możesz uznać widoki Django za kontrolery, a szablony Django za widoki .

Jest to niefortunne zamieszanie spowodowane różnymi interpretacjami MVC.

W interpretacji MVC Django, widok opisuje dane, które są prezentowane użytkownikowi; niekoniecznie chodzi tylko o to, jak wyglądają dane, ale jakie dane są prezentowane.

Z kolei Ruby on Rails i podobne frameworki sugerują, że zadaniem kontrolera jest decydowanie, które dane zostaną zaprezentowane użytkownikowi, podczas gdy widok jest ściśle określony, jak dane wyglądają, a nie jakie dane są prezentowane.

Samo FAQ Django jest dobrym miejscem do rozpoczęcia:

• https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the -view-the-template-how-come-don-t-use-the-Standard-names

W naszej interpretacji MVC „widok” opisuje dane, które są prezentowane użytkownikowi. Niekoniecznie zależy to od wyglądu danych, ale jakie dane są prezentowane. Widok opisuje, jakie dane widzisz, a nie jak je widzisz. To subtelne rozróżnienie.

...

Ponadto rozsądne jest oddzielenie treści od prezentacji - w tym miejscu pojawiają się szablony. W Django „widok” opisuje, które dane są prezentowane, ale widok zwykle jest delegowany do szablonu, który opisuje sposób prezentacji danych.

Gdzie zatem mieści się „kontroler”? W przypadku Django jest to prawdopodobnie sam framework: maszyna, która wysyła żądanie do odpowiedniego widoku, zgodnie z konfiguracją adresu URL Django.

Jeśli jesteś spragniony akronimów, możesz powiedzieć, że Django jest frameworkiem „MTV” - to znaczy „model”, „szablon” i „widok”. Ten podział ma o wiele więcej sensu.

Należy pamiętać, że „Model View Controller” to tylko wzorzec, czyli próba opisu wspólnej architektury. Więc lepszym pytaniem może być „Jak dobrze Django pasuje do wzorca kontrolera widoku modelu?”

Kiedy kodujesz, nie myśląc o nazwach fragmentów frameworka, nie ma istotnych różnic między, na przykład RoR. Ale to zależy od tego, jak dasz użytek models, ponieważ w Django z łatwością zawierają pewną logikę, która w innych frameworkach pozostałaby na poziomie kontrolera.

viewNa Django wydaje się być zbiorem zapytań dla danych pobierania i przekazać je do szablonu.

W mvt żądanie adresu URL jest wysyłane do widoku. Ten Widok wywołuje Model, wykonuje manipulacje i przygotowuje dane do wyjścia. Dane są przekazywane do szablonu, który jest renderowany jako emitowany jako odpowiedź. najlepiej w frameworkach internetowych kontroler jest niewidoczny.

Tutaj różnica jest z MVC: w mvc użytkownik współdziała z GUI, kontroler obsługuje żądanie i powiadamia model, a widok wysyła zapytanie do modelu, aby wyświetlić wynik użytkownikowi.