django: Grube Modelki i chude Kontrolery?

MVC nie jest uniwersalnym rozwiązaniem i przez większość czasu robi się źle i nie może dotrzymać obietnic: w praktyce modyfikowanie modelu będzie wymagało modyfikacji również w kontrolerze, ponieważ jest zrobione źle. Jeśli naprawdę chcesz luźnego połączenia między modelem a kontrolerem , to-a ludzie zwykle to ignorują-musisz użyć wzorca usługi (otwartego jako obrazek). Czego prawie nikt nie robi.

Zamiast ślepo przylegać do MVC / pseudo-wzorca w w świecie PHP, Django przyjmuje pragmatyczne podejście . Ponieważ we wspólnej rzeczywistości tworzenia oprogramowania, programista programuje rzeczy dla użytkownika, aby zobaczyć. Następnie użytkownik (twój szef, klient, klienci ...) "zobaczy" Twoją pracę i ostatecznie wyda swoją opinię o tym, jak chce ją "zobaczyć" w końcu. Używając Django, deweloper może przyjąć bardziej" zorientowany na widok " schemat rozwoju i zgadnij co: to sprawia, że terminy są łatwiejsze do uszanowania, a użytkownicy bardziej zadowoleni. Jeśli się nad tym zastanowisz, ma swój" NoSQL-owski " pomysł, że widok (widok ogólny, Nie widok django) powinien być szefem tego, co dzieje się za kulisami.

Chciałbym podziękować Django za to, że nie zrobił źle MVC, w przeciwieństwie do 99% implementacji PHP MVC.

Z drugiej strony, Django jest jedynym frameworkiem, który pozwala na właściwą izolację pomiędzy aplikacjami. Każda aplikacja może mieć:

• modele
• views
• szablony
• URL
• static pliki
• testy
• formularze
• opcjonalne dodatki (adminy, filtry dla Ajax-selects, uprawnienia dla Django-authority, powiadomienia dla django-notifications, etc, etc)

Więc nawet jeśli twoje modele / widoki/szablony będą powiązane, Twój projekt może być odpowiednio podzielony na małe (również czyta: łatwe w utrzymaniu) i luźno powiązane aplikacje. Tylko powiązane modele/widoki/szablony/rzeczy są powiązane ze sobą. Big fat models script with a big fat views and URL skrypt nie jest tym, czego chcesz w Django. Na przykład nie chcesz, aby dwie klasy modelu, takie jak Article I FootballMatch, żyły razem, chcesz stworzyć aplikację "artykuły" / "blog" i Aplikację "sport", która może żyć niezależnie. Oczywiście czasami muszą być powiązane, w takim przypadku jest to wykonalne na poziomie projektu w 90% przypadków (stworzyłbyś inną aplikację, "blog_sport", gdybyś musiał powiązać Modele lub templatetagi).

Na przykład, bardzo powszechną praktyką jest definiowanie metoda get_absolute_url () w klasie modelu. Tak, twoja klasa modelu, która teoretycznie musi zawierać tylko logikę biznesową, jest teraz powiązana z definicją adresów URL. Jak źle to wygląda w praktyce ?!! W rzeczywistości jest to genialne, ponieważ dodanie tej metody zajmuje dwie sekundy, a następnie można jej używać wszędzie, gdzie używasz modelu: czy to w widokach czy szablonach. Również inne aplikacje(np. django.contrib.admin) użyje go.

Innym nieco bardziej skomplikowanym przykładem geniuszu Django jest to, że zapytania są leniwie oceniane. Co oznacza, że funkcja/Klasa widoku zdefiniuje zapytanie takie jak blog_list = Blog.obiektów.all (), ale zapytanie zostanie faktycznie wykonane w szablonie, jeśli wywoła Jak {%for blog in blog_list %}. Więc logika biznesowa dzieje się w szablonie w tym przypadku, a jeśli coś nie powiedzie się przed renderowaniem szablonu: zapisałeś zapytanie. Ale to nie wszystko, jeśli szablon wyświetla liczbę {{blog_list.count }}, zapytanie select nie zostanie wywołane w ogóle i tylko zapytanie count zostanie wykonane. "Widok ogólny" decyduje, jaka logika biznesowa jest potrzebna. To dalekie od obietnic MVC, ale bądźmy szczerzy: jak praktyczne to jest ?

Chodzi mi o to, że możesz zastosować teorię w niewłaściwy sposób, zrobić to dobrze (co zmniejsza twój wybór do polubienia 5 web frameworków ze wszystkimi językami), lub po prostu przejść do rzeczy w elegancki i pragmatyczny sposób, aby wykonać swoją pracę w sposób Zen w mgnieniu oka: to wybór Django.