Folge 11 – Das CRUD-Pattern
CRUD – Alptraum und Lebenselexier jedes Entwicklers. 
CRUD steht für CREATE READ UPDATE DELETE und sind die 4 Daten-Operationen, die man einbauen muss, um eine sinnvolle Oberfläche oder API zu designen.
CREATE – irgendwie muss man den Datensatz erstellen können. Ein Anlege-Formular muss die Felder des Datensatzes leer oder mit Default-Werten gefüllt anbieten. Per Knopfdruck wird der Datensatz erstellt.
READ – Bei den Leseoperationen gibt es generell 2 Arten: Die Liste bzw. Tabelle, in der man ALLE Datensätze sieht: Tabellarisch, durchsuchbar, filterbar; Und dann gibt es noch den Detail-View, also die Detail-Ansicht. Während man in der Tabelle die Spalten weglässt, die nicht unbedingt für eine Suche oder das Wiederfinden von Datensätzen notwendig sind, sind im DetailView dann alle Daten eingeblendet. Handelt es sich im relativ einfache Datensätze wie z.B. eine einfache Relation mit 2 Spalten, kann man den DetailView auch weglassen.
UPDATE – Das Update-Formular ist wie das Create-Formular aufgebaut: Die Spalten, die man noch bearbeiten können soll, werden mit den bisherigen Daten des Datensatzes gefüllt, man bearbeitet diese und drückt auf Speichern.
Viele Entwickler versuchen, Zeit zu sparen und lassen immer wieder CRUD-Operationen weg. Meist leidet darunter die UPDATE-Funktion. Auf diese kann man noch am ehesten verzichten: anstatt einen Datensatz zu bearbeiten kann ihn ja der User löschen und neu anlegen. 
DELETE – Beim Löschen gibt man meistens dem Nutzer noch einmal die Möglichkeit, vor dem Löschen zustimmen zu müssen.
All diese 4 CRUD-Operationen für jeden Datensatz umzusetzen ist eine WAHNSINNS Arbeit.
Doch Entwickler, die auch nur eine davon weglassen, produzieren damit schlechte Software.
Als Entwickler solltest du lieber schauen, dass du dir ein einheitliches System überlegst, mit dem du für jeden beliebigen Datensatz deine CRUD-Operationen AUTOMATISCH bekommst.
Ein solches System ist die FOP-Programmiersprache. Beim FOP entwickelt man ein Datenschema und bekommt eine Oberfläche zum Manipulieren der Daten gratis dazu. Wenn du wissen willst, wie man FOP benutzt, wie man damit unheimlich schnell Web-Portale und komplexe Software-Projekte erstellt, dann abonniere diesen Podcast.

Folge 11 – Das CRUD - Pattern

Saubere Programmierung – was ist „schöner Code“? Folge 1: Separation of Concerns

Die meisten Entwickler lernen Programmieren durch ihren Spieltrieb – sie setzen sich das Ziel, eines Tages Spiele programmieren zu können oder wollen ein eigenes Web-Portal betreiben, vielleicht das nächste Facebook aufbauen.

In dieser Phase geht es einfach nur darum, Sachen zum Laufen zu bekommen. Es wird Code rauskopiert, neu zusammengesetzt, getestet – bis alles funktioniert.

Ich will euch heute eine neue Sichtweise auf Code beibringen, die über das reine „Funktionieren“ hinausgeht. Quasi um „schönen Code“

Ein paar Basics wird bestimmt jeder mal gehört haben: Variablen aussagekräftig benennen, Funktionsnamen sinnvoll wählen. Ich will euch aber einen weiteren Aspekt beibringen, der dich in deinem Programmiererleben viel Nacharbeit ersparen wird: Die Rede ist vom „Separation of Concerns“.

Ein Concern, englisch, bedeutet „Anliegen“. Ein Anliegen ist zum Beispiel: „ich will mich einloggen können“ – ein anderes Anliegen ist „ich will eine Bestellung erfassen können“ – ein anderes „die Bestellungen sollen mit dem Lagerprogramm synchronisiert werden“

In der Uni lernt ihr eine Denkweise des Separation of Concern: Die MVC oder Model View Controller Sichtweise. Die besagt, dass ihr den Code für das Datenschema, die UI-Darstellung, sowie das Verhalten eurer Objekte code-technisch auf mehrere Dateien aufteilen sollt.

Das Ziel hinter MVC ist sicherlich ein ehrbares. Aber die Stelle, an der hier der Querschnitt gemacht wird, gefällt mir nicht. Ich kann euch das an einem einfachen Beispiel zeigen:

Ihr habt mehrere Concerns, ein Concern ist dass ihr die Adresse im Kunden speichern wollt für den Postversand. Ein anderer Concern ist, dass ihr die Bankverbindung speichern müsst, um die SEPA-Lastschrift durchführen zu können. Unterteilt man die Software jetzt Objektorientiert nach MVC, schmeißt man beide Concerns 1. ins selbe Objekt und 2. auch gemeinsam in die View-Datei.

Die Folge: Will der Kunde jetzt das SEPA-Lastschrift-Feature doch nicht mehr, müsst ihr anfangen, die Dateien zu zerpflücken. Das führt zu Fehlern, blinde Felder, toter Code usw. - Hätte man die Concern-Grenzen besser gesetzt, hätte man nur eine Datei löschen müssen und das SEPA-Feature wäre sauber aus der Software wieder herausgeschnitten.

Die genauen Techniken, wie man diese scharfe Trennung der Concerns erreicht, kommt aus dem Bereich Aspect Oriented Programming und Feature Oriented Programming. Ich werde die Techniken in dieser Folge nicht erklären – dazu wird es noch viele Folgen geben. Ich will euch nur zeigen, dass das Thema sauberer Code komplex ist und du noch viele Verbesserungen an deinem Code erlernen kannst.

Wenn dich das Thema interessiert, dann abonniere diesen Podcast und höre dir die anderen Folgen noch an.

Saubere Programmierung – was ist „schöner Code“? Folge 1: Separation of Concerns

Carl-Philip Hänsch

Related tracks