Wenn wir versuchen, das Ansichtskonzept zu etablieren, wollen wir nicht versuchen, es mit dem Konzept zu vergleichen, das wir in anderen MVC-Umgebungen vordefinieren können. Sobald wir das Konzept der Django- Ansicht haben, können wir es anderen Entwicklern gegenüber besser ausdrücken.
Das Skelett des Sehens
Wenn wir den Hauptteil der Ansicht sehen und zu den Grundlagen der Ansicht gehen, können wir sagen, dass eine Ansicht eine Funktion ist, die eine HTTP-Anforderung entgegennimmt und eine HTTP-Antwort zurückgibt . Wir könnten jedoch sagen, dass dieser Ansatz einfach ist, wenn wir den Zweck von sehen Die Ansicht, die dieses Konzept erfüllt, ist nun ausreichend, da wir andere Aktivitäten ausführen müssen, um die Einfachheit dieser beiden Elemente zu erreichen.
Generische Ansichten
Djangos Philosophie besagt, dass wir alles Mögliche tun müssen, damit unsere Anwendungen wiederverwendbar, einfach und effektiv sind, was bedeutet, dass wir keine sich wiederholenden Elemente entwickeln können, das heißt, wir müssen immer wieder denselben Code schreiben. Es macht keinen Sinn, sehen wir uns das folgende Bild an:
In diesem Code sehen wir, wie wir eine Funktion erstellen. Diese Funktion stellt eine Ansicht dar. Sie ist jedoch keineswegs eine Lösung, die die Punkte der Django-Philosophie erfüllt, obwohl es stimmt, dass der Code funktioniert und in vielen Fällen die Arbeit mehr erledigt Stellen Sie sich vor, wir müssten nicht nur diese Ansicht, sondern 100 oder 200 ausführen, weil wir eine große Anwendung haben. Wir müssten diese Logik immer wieder wiederholen und denselben Codetyp generieren.
Wenn wir den Namen der Ansicht, die Parameter, die sie aufruft, einschließlich der Antwort, die sie gibt, um auf eine vom Entwickler vordefinierte URL zu verweisen, betrachten, verweist dies alles auf eine bestimmte Ansicht und nicht auf eine generische.
Bevor wir uns Sorgen machen können, hat das Framework bereits eine Lösung für dieses Problem und ist nicht mehr und nicht weniger als die generischen Ansichten . Dies sind Ansichten, die bereits definiert sind. Wir müssen nur einem Modell beitreten, eine Vorlage angeben und können auf Funktionen zugreifen und Methoden, die alle Grundlagen erfüllen, die wir haben sollten.
Sehen wir uns den Code dieser allgemeinen Ansichten in der folgenden Abbildung an:
Im Beispiel können wir einige interessante Punkte feststellen. Zuerst beschränken wir die Funktion nicht auf ein einzelnes Modell. Wir sehen, wie wir die model.get_default_manager- Funktion verwenden, mit der wir den Primärschlüssel unseres Modells ermitteln. Dann geben wir den Namen der Vorlage zurück, die wir zuerst erhalten haben als Argument der Funktion.
Hier gibt es keine Code-Beschränkungen mehr, da dies nur einmal durchgeführt wird und Django einschließt. Wir müssen uns nur darum kümmern, zu integrieren, was wir verwenden werden. Schauen wir uns die Implementierung einer Ansicht mit diesem Ansatz an:
In unserer Implementierung rufen wir einfach die Funktion show_object der Klassenansichten auf , geben an, welches Modell verwendet wird, und geben den Namen der Vorlage an. Dies ist weniger repetitiv und einfacher als der nicht generische Ansatz, den wir zu Beginn sahen.
Wie wir sehen konnten, verfügen wir über Tools innerhalb des Frameworks, die uns Arbeit ersparen, und wir können auch die Philosophie einer sauberen und effizienten Entwicklung erfüllen, indem wir die Anzahl der unnötigen Codezeilen verringern, die wir schreiben.
