Django kontra kontroler widoku modelu [zamknięty]

110

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?

django model-view-controller frameworks

— Leonardo
źródło

2

Kiedy mówisz „kontroler widoku modelu”, czy masz na myśli ogólny wzorzec, czy konkretną implementację (jak Ruby on Rails)?

— Paul D. Waite,

33

To pytanie nie kwalifikuje się jako „nie konstruktywne” i ma prostą odpowiedź bez „debaty, argumentów, sondaży lub rozszerzonej dyskusji”. Po co więc go zamknąć?

— użytkownik

6

nie konstruktywne? TAK super mody znów uderzają.

— Amit Tripathi,

4

Na dzień dzisiejszy prawie 24 000 osób uznało to pytanie za konstruktywne. Włącznie ze mną.

— frozenjim,

3

Od 2017 to pytanie jest nadal konstruktywne

— Leonardo Pessoa

140

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.

— Paolo Moretti
źródło

6

Dzięki za świetną odpowiedź. Przechodząc z Rails do Django, ta odpowiedź jest jedną z najbardziej frustrujących: dlaczego django umieszcza kod kontrolera w pliku o nazwie views.py !?

— dgmdan

@dgmdan To tylko domyślna konwencja, możesz wybrać nazwę, którą lubisz. Ale zgadzam się, to wydaje się dziwne :)

— Paolo Moretti

1

Wolałbym raczej zostawić views.py jako warstwę widoku i utworzyć zestaw klas kontrolera w pakiecie kontrolera, aby uniknąć zamieszania w Django.

— stanleyxu2005

5

@dgmda: Ponieważ pojęcie „kontrolera” jest mylące w aplikacjach internetowych. MVC to platforma sterowana zdarzeniami, która nie pasuje tylko do bezstanowego modelu żądania / odpowiedzi HTTP. Przede wszystkim nie należy go nazywać MVC. Prawie wszystkie aplikacje internetowe nie są MVC, ale używają modelu i funkcji lub klasy zwykle nazywanej widokiem. Widok z kolei może delegować renderowanie HTML do szablonu, ale nie musi. Więc właściwie nie ma kontrolera.

— Lennart Regebro

2

Popieram koncepcję Lennarta Regebro, że model bezstanowy, taki jak HTTP, nie powinien mieć kontrolera, a model MVC dla aplikacji internetowych po prostu powoduje poważne zamieszanie

— Hussam

23

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

— Paul D. Waite
źródło

3

To chyba najbardziej bezpośrednia odpowiedź.

— użytkownik

11

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.

— inigomedina
źródło

10

A viewsw Django jest czymś w rodzaju a controllerw MVC, a a templatew Django jest bardziej prawdopodobne aviews

— Roel

7

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.

— Samuele Mattiuzzo
źródło