Schönen Sonntag allerseits!
Ich habe mich in der letzten Woche mal hingesetzt und mir überlegt, wie ich die Verwaltung von Modulen in einem "Framework" möglichst abstrakt umsetzen könnte.
Ich habe mich auf zwei Klassen verständigt, ModuleElement und ModuleManager.
Die Klasse ModuleElement arbeitet immer mit einem Element eines Moduls. Attribute sind der Modulname und die ID, die Methoden Add(), Delete(), Edit() und Get. Bei Add() und Edit() werden jeweils die Felder via Parameter als Array übergeben.
So kann eine News in etwa so hinzugefügt werden.
Das Bearbeiten erfolgt auf ähnliche Weise:
Analog verhält es sich beim Löschen und Zurückliefern der News (natürlich ohne das Array) via Get().
Das Zurückliefern der News soll nun aber nicht exklusiv über diese Klasse gehandhabt werden, da sie sich, wie der Name schon sagt, stets nur mit einem Element eines Moduls beschäftigt.
Hierfür wäre die Klasse ModuleManager zuständig. Parameter benötigt sie nicht, instanziiert werden soll sie auch nicht.
Methoden der Klasse ModuleManager sind Get() zum Auslesen eines einzigen Elements, GetInterval(), um ein Intervall von Elementen auszulesen, und GetConfig() zum Auslesen der Konfiguration aus der Datenbank.
Ablaufen würde das in etwa so:
Hier muss natürlich immer überprüft werden, ob die entsprechende Tabelle (wessen Name das Modul quasi repräsentiert) und deren Felder existieren.
Vielleicht wäre hier auch eine Art Rohling nützlich, um das Modell einer Tabelle auch im Code selbst zu definieren.
Nützlich wäre zudem wohl noch eine Methode, um die Gesamtanzahl der Einträge auszulesen.
Ansonsten wäre ich mit der Präsentation dieser Realisierung erst einmal am Ende angelangt. Meine Fragen: Ist das alles soweit verständlich? Ist der Realisierungsansatz sinnvoll oder nicht? Gibt es hier oder da vom Konzept her Sackgassen, die zu Problemen führen werden? Oder fehlt es einfach noch an Features, die ihr hinzufügen würdet?
Wäre dankbar für jede Kritik, jeden Rat oder Hinweis.
Mit freundlichen Grüßen
Matze
EDIT: Ich sehe gerade, dass dieses Thema vielleicht eher in den Bereich Software-Design passt. Sorry dafür.
Ich habe mich in der letzten Woche mal hingesetzt und mir überlegt, wie ich die Verwaltung von Modulen in einem "Framework" möglichst abstrakt umsetzen könnte.
Ich habe mich auf zwei Klassen verständigt, ModuleElement und ModuleManager.
Die Klasse ModuleElement arbeitet immer mit einem Element eines Moduls. Attribute sind der Modulname und die ID, die Methoden Add(), Delete(), Edit() und Get. Bei Add() und Edit() werden jeweils die Felder via Parameter als Array übergeben.
So kann eine News in etwa so hinzugefügt werden.
PHP-Code:
<?php
// Inhalt der News
$NewsContent = array('Titel' => 'Testtitel', 'Datum' => time(), 'Inhalt' => 'Testinhalt');
// News hinzufügen
$News = new ModuleElement('news');
$News->Add($NewsContent);
?>
PHP-Code:
<?php
// Inhalt der News
$NewsContent = array('Titel' => 'Testtitel', 'Datum' => time(), 'Inhalt' => 'Testinhalt');
// News bearbeiten (ID der News = 6)
$News = new ModuleElement('news', 6);
$News->Edit($NewsContent);
?>
Das Zurückliefern der News soll nun aber nicht exklusiv über diese Klasse gehandhabt werden, da sie sich, wie der Name schon sagt, stets nur mit einem Element eines Moduls beschäftigt.
Hierfür wäre die Klasse ModuleManager zuständig. Parameter benötigt sie nicht, instanziiert werden soll sie auch nicht.
Methoden der Klasse ModuleManager sind Get() zum Auslesen eines einzigen Elements, GetInterval(), um ein Intervall von Elementen auszulesen, und GetConfig() zum Auslesen der Konfiguration aus der Datenbank.
Ablaufen würde das in etwa so:
PHP-Code:
<?php
// Intervall auslesen (Modulname, Start-ID, End-ID und Sortiermethoden als Paramter)
$NewsArray = ModuleManager::GetInterval('news', 1, 30, 'ID', 'DESC');
// Eine News auslesen (ID = 6)
$News = ModuleManager::Get(6);
// Konfiguration auslesen
$NewsPerPage = ModuleManager::GetConfig('news', 'perpage');
?>
Vielleicht wäre hier auch eine Art Rohling nützlich, um das Modell einer Tabelle auch im Code selbst zu definieren.
Nützlich wäre zudem wohl noch eine Methode, um die Gesamtanzahl der Einträge auszulesen.
Ansonsten wäre ich mit der Präsentation dieser Realisierung erst einmal am Ende angelangt. Meine Fragen: Ist das alles soweit verständlich? Ist der Realisierungsansatz sinnvoll oder nicht? Gibt es hier oder da vom Konzept her Sackgassen, die zu Problemen führen werden? Oder fehlt es einfach noch an Features, die ihr hinzufügen würdet?
Wäre dankbar für jede Kritik, jeden Rat oder Hinweis.
Mit freundlichen Grüßen
Matze
EDIT: Ich sehe gerade, dass dieses Thema vielleicht eher in den Bereich Software-Design passt. Sorry dafür.
Kommentar