CRUD, dieses Vorgehen sollte eigentlich jeder kennen … falls nicht, CRUD ist die Kurzform für „Create, Read, Update and Delete“ und ist vereinfacht gesagt als Checkliste zu sehen und gilt nicht nur für PHP.
Du hast in deiner Anwendung zum Beispiel eine Liste aller User, die soll editierbar sein. Du kannst nun CRUD als Checkliste benutzen und einzeln abhaken:
- Create: Kann ich neue User erzeugen? Check!
- Read: Kann ich eine Liste aller User ausgeben UND kann ich im Editfall einen User darstellen? Check!
- Update: Kann ich die Daten eines Users ändern? Check!
- Delete: Kann ich einen User löschen? Check!
Hast du bei allen ein „Check!“, dann bist du technisch auf dem Mindestlevel angelangt. Herzlich Willkommen 😉
Soviel zu Theorie. In der Praxis sehe ich es leider oft, dass CRUD viel zu wörtlich genommen wird. Besonders das C und das U sehe ich oft als zwei Dinge in der Anwendung.
Warum nun ist das schlimm? Nun, ich arbeite mit Legacy-Anwendungen. Diese sind teilweise vor vielen Jahren begonnen und verrichten bis heute ihren Dienst. Innerhalb dieser Anwendungen gibt es immer wieder den Fall, dass eine Datensatzart die CRUD Bedingung erfüllen muss, d.h. ich habe eine Liste von (Beispiel) Usern oder Kunden, die kann man ändern, die kann man neu erzeugen, die kann man löschen usw.
Nun mein Appell an alle: Bitte, fasst C und U zusammen. Bitte!
Es gibt nichts schlimmeres, als dass man ein „create“ Script und ein „update“ Script hat, beide machen im Prinzip das gleiche (Prüfung der Daten, Normalisieren der Daten usw.), aber im Endeffekt hast du 2 Scripte. Du hast also „duplicate code“. Und das ist nicht nur „bad smell„, dies ist einfach nur „bad style“. Eine Änderung an der Logik der User (Stichwort neues Feld) und du musst beide Scripte aktualisieren. Falls deine Anwendung mehrere solcher Listen hat und das neue Feld mehrere betrifft darfst du die „2“ gern entsprechend faktorisieren.
Also, bitte, bau die ein „edit“ Script, prüfe die Variablen, normalisiere diese und mache alles fertig. Dann nur noch die Unterscheidung „neu“ oder „ändern“ und gut ist. Das sind aus meiner Erfahrung nur ein if-else (oder switch) und das entsprechende SQL-Kommando. Die Ausführung des Kommandos ist dann ja wieder das selbe und kann außerhalb der Verzweigung stehen.
Dieses eine Script läßt sich jetzt viel leichter skalieren, verstößt nicht mehr gegen den „copy paste detector“ und läßt dich einfach ruhiger schlafen.
Just my 2 cent ….
Symfony2 macht das auch so. Es gibt je eine Action im Controller fürs Anlegen und Bearbeiten einer Entity. Die gehen sogar noch etwas weiter und haben dazu jeweils eine Action, um die Daten zu verarbeiten. Es kommt immer darauf an, was man machen will. Mit verschiedenen Actions/Scrips bist du freier und hälst den Code sauberer, wenn z.B. die Formulare anders gestaltet sein sollen oder verschiedene Rechte vergeben werden sollen. In anderen Projekten habe ich das auch oft mit einer Edit-Action gelöst. Hat alles seine Vor- und Nachteile.
Wenn du wirklich was anderes beim Create machst wie beim Update, dann ist das auch okay. Aber zu +90% machst du das selbe und dafür brauchst du keine extra Action und kannst damit Copy-Paste-Fehler vermeiden. Ich sprach daher mehr von der Regel aus von der begründeten Ausnahme 😉