Ein Blog

30 Artikel

MAVUT - Ein strukturiertes Vorgehen bei der Entwicklung von Django Applikationen

Django ist in sich sehr strukturiert, d.h. Funktionalitäten werden explizit getrennt verwaltet. Es bietet die Unterteilung in Apps und auf "tieferer" Ebene, den Model, View, Template Ansatz, sowie viele weitere Gliederungen, die sich teilweise in der Django Community etabliert haben (z.B. Testdatei nach Testobjekt zubenennen "test_form_..., test_view_...). Was noch fehlt ist ein Leitfaden / strukturiertes Vorgehen für die Entwicklung.

Womit fängt man am Besten an, wenn man eine neue Django Applikation aufbaut?

In Tutorials zu Django werden häufig zunächst die Zugriff-Urls in urls.py definiert, dann die zugehörige View in views.py geschrieben, dabei wird das Model eingeschoben, bzw. geändert, wenn noch Daten fehlen. Zum Schluss wird das HTML-Template für die Ansicht des Datenkontextes erstellt.

Oder es wird auf Basis eines HTML-Templates begonnen und Model, View und Urls darunter gebaut.

Sicherlich gibt es hier noch diverse andere Möglichkeiten, dennoch glaube ich, dass in den meisten Fällen die Reihenfolge "MAVUT" (Model, Admin, View, Urls, Template) sinnvoll ist.

Diese Reihenfolge entspricht am ehesten dem Ansatz "Form Follows Function" und setzt damit die frühzeitige Prüfung der Funktionen einer Applikation in den Fokus.

  1. Model - Bei der Informationsverarbeitung geht es vornehmlich und die Verarbeitung von Daten (Input, Output). Die Anforderungen zu den Daten als erstes zu erfassen bzw. direkt in ein Model zu implementieren ist daher beinahe selbstverständlich. Mit den Datenmodellen zu einer App / den Apps zu starten hilft ungemein sich schon frühzeitig Gedanken dazu zu machen bzw. erkennen zu können, ob man die für den Anwender relevanten Daten verarbeiten kann.

  2. Admin - Das Admininterface ist eines der herausragenden Merkmale von Django. Diese mitgelieferte CRUD-Sicht auf die selbst definierten Datenmodelle, lässt sich beinahe aufwandslos registrieren. Nachdem bzw. auch parallel zur Entwicklung der Datenmodelle sollte man die jeweilige Adminsicht registrieren und ggf. für sich anpassen. Diese andere Sicht auf die zu verarbeitenden Daten lässt einen Lücken oder Fehler nochmals besser erkennen und hilft somit nötige Anpassungen am Datenmodel frühzeitig zu erkennen.

  3. View - Die Aufbereitung / das Zusammenziehen / Extrahieren der Daten und die Logik für die Sichtung durch den Nutzer ergibt den nächsten Schritt. Diese "Aufgabe" ist größtenteils unabhängig davon, auf welche Art die Daten am Ende dargestellt werden (,ob z.B. per HTML-Template oder per REST-API in einer separaten Frontend-App). Zudem definiert man somit im Vorfeld bereits die Namen der Funktionen / Importe für die URL Konfiguration.

  4. Urls - Die Urls liefern dem Endanwender den Zugriff auf die angebotenen Daten / Inhalte. Es ist sinnvoll diese erst dann festzulegen, wenn man genau weiss und überprüft hat, welche Funktionen eine View zur Verfügung stellen wird. Aussagekräftige URLs helfen nicht nur dem Anwender.

  5. Template - Die Art und Weise der Darstellung sollte zu allerletzt festgelegt werden. Ggf. ist es sogar sinnvoll zunächst innerhalb der Templates auf weitere Verfeinerungen durch CSS etc. zu verzichten. Resilient Webdesign ist hierzu das Stichwort. Was hilft es, wenn eine Anwendung für 85% der Nutzer gut aussieht, aber für die restlichen 15% nicht nutzbar ist. Will heißen, Bootstrap und Co. sollten zunächst nicht im Fokus stehen.

Bleibt anzumerken, dass es sicherlich immer wieder Fälle gibt, in denen eine andere Reihenfolge genauso sinnvoll seien kann :)

mathiasmell 18. März 2019 22:23 django , best-practise

1 Kommentar

  • Sehr interessanter Artikel. Ich hoffe es kommt noch mehr. Django braucht diese Artikel