nicht angemeldet Matti Mäkitalo
suit
dedlfix
dedlfix
dedlfix
Matti Mäkitalo
MudGuard
dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
Matti Mäkitalo
dedlfix
hi,
ich arbeite jetzt schon über 15 Jahre als Entwickler, aber so richtig warm bin ich mit PHP-Frameworks noch nie geworden. So richtig den Sinn habe ich davon auch noch nicht verstanden.
wir arbeiten in unserer Firma in zwei Teams: wir, die einen, die "Alten", arbeiten eher agil, d.h. pures Coding, sicherlich viel Redundanz, sicherlich vieles Quick&Dirty, sicherlich vieles nur 95%, sicherlich vieles nicht für die Ewigkeit. Ich sage mal, wir sind extrem erfolgreich mit unserer Abteilung. Vor allem sind wir schnell. Die andere Abteilung, die Jugend, nutzt das Zend-Framework bzw. Symfony2. Da dockerten jetzt 10 Leute an einer Applikation seit ca.1 Jahr rum, die die agile Abteilung in 4 Wochen geschrieben hätte. Vielleicht nicht so hübsch, aber dafür lauffähig. Vor allem schwächelt die Symfony2-App an jeder Ecke...
Ich habe mir Symfony2 mal näher angeguckt. Ich sag mal, ich finde das ziemlich abtörnend mit der ganzen Konfiguration. Sicherlich nette Aspekte dabei, aber den Hype dahinter verstehe ich nicht. Vielleicht bin ich zu alt.
Ebenso gings mir mit Django, Cake, und noch ein paar anderen. Das einzige Framework, was ich wirklich nutze, ist Jmonkey. Aber das ist ne andere Baustelle.
Also, was haltet ihr von PHP-Frameworks? Nötig? Überbewertet? Unsinnig? Wer arbeitet damit?
ach so, vor allem habe ich immer das Gefühl, diese Framework-Dinger sind so laaaangsam... kann mir nicht helfen.
Hi,
ach so, vor allem habe ich immer das Gefühl, diese Framework-Dinger sind so laaaangsam... kann mir nicht helfen.
dev-Umgebung von Symfony2 (ohne Cache)?
Bis die Tage,
Matti
Moin!
ach so, vor allem habe ich immer das Gefühl, diese Framework-Dinger sind so laaaangsam... kann mir nicht helfen.
Ungetuned ist Symfony wohl so in der Nähe von 60 Millisekunden "time-to-first-byte". PHP standalone kann das schneller, aber nicht unendlich viel schneller - ich würde meinen, 20 Millisekunden.
Ja, da ist Symfony dreimal langsamer für diesen Hello-World-Case. Wer nur statischen Content ausliefern muss und das optimieren will, sollte vermutlich was anderes nehmen. Normalerweise muss Code aber auch noch was relevantes tun, und darum kommt man ja auch nicht drumherum. Die Businesslogik, die DB-Abfragen etc. verbrauchen ja in beiden Fällen identisch viel Zeit. Angenommen, das wären 100 ms, dann ist der Overhead durchs Framework ja nur noch 120ms zu 160ms. Das ist nur noch ein Drittel langsamer. :)
- Sven Rautenberg
ach so, vor allem habe ich immer das Gefühl, diese Framework-Dinger sind so laaaangsam... kann mir nicht helfen.
Falls es dir wirklich auf Geschwindigkeit ankommt, musst du sowieso weg von PHP und zum Beispiel auf ASP.NET oder SSJS umstellen.
Grüße,
Die andere Abteilung, die Jugend, nutzt das Zend-Framework bzw. Symfony2. Da dockerten jetzt 10 Leute an einer Applikation seit ca.1 Jahr rum, die die agile Abteilung in 4 Wochen geschrieben hätte.
warum gibt es die zweite abteilung bzw. warum dürfen die dann den "langen weg" gehen?
MFG
bleicher
So richtig den Sinn habe ich davon auch noch nicht verstanden.
Ganz einfach formuliert:
Einsparen von Entwicklungszeit auf Kosten von Performance
Also, was haltet ihr von PHP-Frameworks? Nötig? Überbewertet? Unsinnig? Wer arbeitet damit?
Ich arbeite vorwiegend mit "TYPO3" also mit dem unbenannten Framework, da ja FLOW3 und ext_base noch nicht wirklich "fertig". Mit der nötigen Erfahrung arbeitet man damit wesentlich schneller (und weniger Fehleranfällig) als zu Fuß.
Ein Beispiel ist eine simple Abfrage um alle Datensätze aus dem Seitenbaum (flach) abzuholen die angezeigt werden dürfen:
$query = $GLOBALS['TYPO3_DB']->SELECTquery(
"*",
"pages",
"1=1" . $this->cObj->enableFields('pages'),
);
$res = $GLOBALS['TYPO3_DB']->sql(TYPO3_db, $query);
while($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
$this->pages[] = $row;
}
Unter dem Strich ist das nicht wesentlich kürzer als das ganze per Hand mit mysql(i)-Funktionen zu schreiben, hat aber den essentiellen Vorteil, dass man sich um nichts kümmern muss.
Die Abstraktionsschicht sorgt dafür, dass ich nur Tabellen und Felder Benutzer kann, die auch tatsächlich für TYPO3 bekannt sind und existieren (als in ext_tables.php konfiguriert sind). Dass jemand mittles einer Injection Informationen aus einer anderen, nicht zum CMS gehörigen Tabelle in derselben Datenbank abholt ist weitgehend ausgeschlossen. Weiters muss ich mich nicht um die Datenbankverbindung selbst kümmern - ob das jetzt MySQL ist oder ein anderes DMBS spielt hier keine Rolle ADOdb "wirds schon richten".
Die enableFields-Methode sorgt davor, dass automatisch Bedingungen gesetzt werden, die das Abfragen "verbotener" Datensätze unterbinden: sprich hier werden einfache Dinge wie "Datensatz ist gelöscht" oder "erst ab einem gewissen Zeitpunkt aktiv" automatisch geprüft, selbstverständlich werden auch erweiterete Dinge wie z.B. Benutzer- und Gruppenrechte geprüft - ensprechend dem, was (wie auch zuvor) in ext_tables definiert ist. Zusätzlich wird noch der Workspace geprüft.
Im Klartext sieht die Prüfung (ohne rekursiv Rechte im Baum zu beachten) so aus - für Abfragen bei einer aktiven Benutzersession kommt noch einiges dazu.
AND pages.deleted=0 AND pages.t3ver_state<=0 AND pages.pid!=-1 AND pages.hidden=0 AND pages.starttime<=1347547560 AND (pages.endtime=0 OR pages.endtime>1347547560) AND (pages.fe_group='' OR pages.fe_group IS NULL OR pages.fe_group='0' OR (pages.fe_group LIKE '%,0,%' OR pages.fe_group LIKE '0,%' OR pages.fe_group LIKE '%,0' OR pages.fe_group='0') OR (pages.fe_group LIKE '%,-1,%' OR pages.fe_group LIKE '-1,%' OR pages.fe_group LIKE '%,-1' OR pages.fe_group='-1'))
Wenn man schon lange per Hand gearbeitet hat und dann in ein komplexes Framework einsteigt, dauert das mitunter Jahre bis man auch nur ansatzweise den "kompletten" Umfang kennt - es hat aber den essentiellen Vorteil, dass ein Kenner des Systems ohne Probleme damit arbeiten kann.
Bei obenstehenden Beispiel kann man sich drauf verlassen, dass hier alle nötigen Dinge beachtet werden - wenn jemand auf die Idee kommt, dass er plötzlich bei irgend einer Tabelle die Liste der enableFields um eines erweitert, wissen automatisch alle Abfragen die mit enableFields arbeiten darüber Bescheid und jeder der sich mit dem Framework auskennt wird auch wissen, dass das ein Punkt ist, um den man sich hier nicht kümmern muss.
Der Nachteil ist die Einarbeitungszeit und natürlich der zusätzliche Ressourcenbedarf weil das Framework eine Abstraktionsschicht zwischen Programmierer und Programmiersprache darstellt - aber dafür werden die Anwendungen idR. weniger Fehleranfällig und sind schneller fertig.
Tach!
ich arbeite jetzt schon über 15 Jahre als Entwickler, aber so richtig warm bin ich mit PHP-Frameworks noch nie geworden. So richtig den Sinn habe ich davon auch noch nicht verstanden.
Der Sinn ist, wiederverwendbare Komponenten zu haben und so verschiedene Anwendungen zu erstellen, die alle denselben Unterbau haben, so dass man sich nicht auch noch in die Grundfunktionalitäten jedes einzelnen Systems einarbeiten muss.
wir arbeiten in unserer Firma in zwei Teams: wir, die einen, die "Alten", [...] Vor allem sind wir schnell. Die andere Abteilung, die Jugend, [ist langsam].
Das kann durchaus auch an fehlender Erfahrung liegen, dass die Jugend einfach noch nicht weiß wie man effizient mit den Werkzeugen umgeht und an Problemlösungen herangeht.
Die nächsten Fragen hast du sehr allgemein gefragt, also erwarte bitte keine Entscheidungshilfen.
Also, was haltet ihr von PHP-Frameworks?
Kann man verwenden, wenn man den entsprechenden Bedarf hat.
Nötig?
Natürlich kann man auch ohne arbeiten, also: nein.
Überbewertet?
Kommt auf die Aufgabenstellung an.
Unsinnig?
Sicherlich nicht. (Der Widerspruch zur "Nötig?"-Antwort ist nur ein scheinbarer.)
Wer arbeitet damit?
Was nützt dir die Antwort auf diese Frage für deine eigenen Aufgaben, für die du eventuell ein Framework einsetzen würdest?
dedlfix.
hi,
Also, was haltet ihr von PHP-Frameworks? Nötig? Überbewertet? Unsinnig? Wer arbeitet damit?
Nötig: Ja. Bischen weiter ausgeholt (ich entwickele auch seit 14 Jahren Webanwendungen), PHP verleidet dazu, Code in vielen Dateien zu verteilen. Perl hingegen ist dafür bekannt, dass es immer langsamer wird, je mehr Code beim Laden einer URL kompiliert werden muss.
Es gibt also Gründe, sich Gedanken zu machen und so habe ich ein Perl-FW entwickelt, was nur noch eine einzige ausführbare Datei haben muss, den sog. Bootstrap-Loader. Jeder weitere Code ist in sog. Responseklassen organisiert, das ist extrem überschaubar und auch skalierbar (Mehrspachigkeit, Multidomainfähigkeit, Multiuserfähigkeit). Alle diese genannten Features sind aus dem Code der Responseklassen komplett raus, darum muss sich der Programmierer gar nicht mehr kümmern.
PHP: Mein PHP-FW ist genauso aufgebaut wie mein Perl-FW. Und so habe ich beide FW konsolidiert, d.h., auf meiner Website läuft praktisch ein PHP/Perl-FW, es gibt somit Responsen/Anwendungen die sowohl in PHP als auch in Perl programmiert sind. Der Anwender sieht keinen Unterschied und der Programmierer kann sich auf das Wesentliche konzentrieren.
Anwendungen sind in sehr kurzer Zeit entwickelt, es ist nur eine Klasse zu schreiben (das ist mein Plug-In-Modell). Da macht das Programmieren mit PHP genauso viel Spaß wie mit Perl ;)
Hotti
Hi,
Also, was haltet ihr von PHP-Frameworks? Nötig? Überbewertet? Unsinnig? Wer arbeitet damit?
Nötig: Ja. Bischen weiter ausgeholt (ich entwickele auch seit 14 Jahren Webanwendungen), PHP verleidet dazu, Code in vielen Dateien zu verteilen.
Und du glaubst, letzteres wäre unter Verwendung eines Frameworks anders …?
Nein, eher im Gegenteil.
MfG ChrisB
hi ChrisB,
Also, was haltet ihr von PHP-Frameworks? Nötig? Überbewertet? Unsinnig? Wer arbeitet damit?
Nötig: Ja. Bischen weiter ausgeholt (ich entwickele auch seit 14 Jahren Webanwendungen), PHP verleidet dazu, Code in vielen Dateien zu verteilen.
Und du glaubst, letzteres wäre unter Verwendung eines Frameworks anders …?
In meinem FW konzentriert sich der Code auf max. 4 Methoden in der jeweiligen Anwendungsklasse.
Nein, eher im Gegenteil.
Dahinter steckt eine übersichtliche Klassenhierarchie.
Viele Grüße,
Hotti
Moin Hotti,
also ich kenne dein FW nicht. Unser ehemaliger Entwickler hatte aber genau so ein Konstrukt (wobei es dort nur 2 Methoden waren). Man musste dann für ein neues Modul von einer Klasse ableiten und diese 2 Methoden mit leben füllen. Da der OOP Ansatz an dieser Stelle komplett verschlaffen wurde, wurde einfach jeder Code in diese 2 Methoden gepackt. Es wurde nicht nochmal in Klassen aufgeteilt. Dass führte zu sehr vielen Dateien und immens vielen Redundanzen. Hoffe du hast es besser unter Kontrolle.
Gruß und gute Wünsche
dein (immer noch) Fan
T-Rex
hi T-Rex,
also ich kenne dein FW nicht. Unser ehemaliger Entwickler hatte aber genau so ein Konstrukt (wobei es dort nur 2 Methoden waren). Man musste dann für ein neues Modul von einer Klasse ableiten und diese 2 Methoden mit leben füllen. Da der OOP Ansatz an dieser Stelle komplett verschlaffen wurde, wurde einfach jeder Code in diese 2 Methoden gepackt. Es wurde nicht nochmal in Klassen aufgeteilt. Dass führte zu sehr vielen Dateien und immens vielen Redundanzen. Hoffe du hast es besser unter Kontrolle.
Klar ;)
Warum habt Ihr an der Stelle nicht weitergemacht? Die Ableitung einer Anwendungsklasse als Subklasse einer über bootstrap geladenen Basisklasse ist doch schon OOP und ein ausgezeichneter Ansatz.
Redundanzen vermeiden: Eine Klasse, die einen Artikel in einem Shop präsentiert und das Einfügen in den Warenkorb ermöglicht, schreibe ich nur einmal, alles was die Artikel unterscheidet wird über Attribute geregelt.
Viele Grüße,
Hotti
Tach!
Redundanzen vermeiden: Eine Klasse, die einen Artikel in einem Shop präsentiert und das Einfügen in den Warenkorb ermöglicht, schreibe ich nur einmal, alles was die Artikel unterscheidet wird über Attribute geregelt.
Wenn so unterschiedliche Dinge wie Shop-Artikel nur ein paar wenige Merkmale gemeinsam haben sollen, wäre statt einer Basisklasse eher ein Interface angebracht, das diese Merkmale definiert, die für den Warenkorb interessant sind.
dedlfix.
Moin,
Redundanzen vermeiden: Eine Klasse, die einen Artikel in einem Shop präsentiert und das Einfügen in den Warenkorb ermöglicht, schreibe ich nur einmal, alles was die Artikel unterscheidet wird über Attribute geregelt.
Wenn so unterschiedliche Dinge wie Shop-Artikel nur ein paar wenige Merkmale gemeinsam haben sollen, wäre statt einer Basisklasse eher ein Interface angebracht, das diese Merkmale definiert, die für den Warenkorb interessant sind.
In meinem FW hat die Basisklasse mit einer Warenkorb-Klasse oder mit einer Artikel-Klasse gar nichts zu tun. Schnittstellen werden erst in der jeweiligen Anwendungs- bzw. Responseklasse angesprochen, nämlich dann, wenn sie gebraucht werden.
Schönen Sonntag,
Hotti
Tach!
Wenn so unterschiedliche Dinge wie Shop-Artikel nur ein paar wenige Merkmale gemeinsam haben sollen, wäre statt einer Basisklasse eher ein Interface angebracht, das diese Merkmale definiert, die für den Warenkorb interessant sind.
In meinem FW hat die Basisklasse mit einer Warenkorb-Klasse oder mit einer Artikel-Klasse gar nichts zu tun. Schnittstellen werden erst in der jeweiligen Anwendungs- bzw. Responseklasse angesprochen, nämlich dann, wenn sie gebraucht werden.
Ich habe nichts von einer Gott-Klasse geschrieben und auch keine solche gemeint. Eine Basisklasse ist nicht zwangsläufig die Grundlage für sämtliche Klassen sondern nur für die, die in einem sinnvollen Zusammenhang stehen. Zum Beispiel können alle Controller in einem MVC-Szenario von einer Controller-Basisklasse abstammen. Plugins hingegen von einer Plugin-Basisklasse.
dedlfix.
hi,
Tach!
Wenn so unterschiedliche Dinge wie Shop-Artikel nur ein paar wenige Merkmale gemeinsam haben sollen, wäre statt einer Basisklasse eher ein Interface angebracht, das diese Merkmale definiert, die für den Warenkorb interessant sind.
In meinem FW hat die Basisklasse mit einer Warenkorb-Klasse oder mit einer Artikel-Klasse gar nichts zu tun. Schnittstellen werden erst in der jeweiligen Anwendungs- bzw. Responseklasse angesprochen, nämlich dann, wenn sie gebraucht werden.Ich habe nichts von einer Gott-Klasse geschrieben und auch keine solche gemeint. Eine Basisklasse ist nicht zwangsläufig die Grundlage für sämtliche Klassen sondern nur für die, die in einem sinnvollen Zusammenhang stehen. Zum Beispiel können alle Controller in einem MVC-Szenario von einer Controller-Basisklasse abstammen. Plugins hingegen von einer Plugin-Basisklasse.
Zend-Framework arbeitet ja viel mit abstrakten Klassen
mfg
tami
hi,
hi,
Tach!
Wenn so unterschiedliche Dinge wie Shop-Artikel nur ein paar wenige Merkmale gemeinsam haben sollen, wäre statt einer Basisklasse eher ein Interface angebracht, das diese Merkmale definiert, die für den Warenkorb interessant sind.
In meinem FW hat die Basisklasse mit einer Warenkorb-Klasse oder mit einer Artikel-Klasse gar nichts zu tun. Schnittstellen werden erst in der jeweiligen Anwendungs- bzw. Responseklasse angesprochen, nämlich dann, wenn sie gebraucht werden.Ich habe nichts von einer Gott-Klasse geschrieben und auch keine solche gemeint. Eine Basisklasse ist nicht zwangsläufig die Grundlage für sämtliche Klassen sondern nur für die, die in einem sinnvollen Zusammenhang stehen. Zum Beispiel können alle Controller in einem MVC-Szenario von einer Controller-Basisklasse abstammen. Plugins hingegen von einer Plugin-Basisklasse.
Zend-Framework arbeitet ja viel mit abstrakten Klassen
s.a. http://framework.zend.com/manual/1.0/de/zend.controller.plugins.html
zum Beispiel. Wie auch die Anordnungen von Zend-Framework was Request und Repsonseklassen angeht: http://framework.zend.com/manual/1.12/de/zend.controller.response.html
Schön auch deren API-Doc (mit I-Frames ;-)!!!): http://framework.zend.com/apidoc/1.12/
mfg
tami
Hi,
Redundanzen vermeiden: Eine Klasse, die einen Artikel in einem Shop präsentiert und das Einfügen in den Warenkorb ermöglicht, schreibe ich nur einmal, alles was die Artikel unterscheidet wird über Attribute geregelt.
Alleine an diesem Beispiel wird klar, dass bei dir ebenfalls das Wurstbrot vom Supermarkt erbt, damit man das Wurstbrot kaufen kann.
Die Methode, einen Artikel in einen Einkaufskorb zu legen, gehört IMHO in die Warenkorb-Klasse und nicht in die Artikel-Klasse.
Bis die Tage,
Matti
Hi,
Redundanzen vermeiden: Eine Klasse, die einen Artikel in einem Shop präsentiert und das Einfügen in den Warenkorb ermöglicht, schreibe ich nur einmal, alles was die Artikel unterscheidet wird über Attribute geregelt.
Alleine an diesem Beispiel wird klar, dass bei dir ebenfalls das Wurstbrot vom Supermarkt erbt, damit man das Wurstbrot kaufen kann.
Naja, zumindest ist bei hotti "bestellen" eine Methode des Tisches (der vom Restaurant erbt) ...
cu,
Andreas
Hi,
Naja, zumindest ist bei hotti "bestellen" eine Methode des Tisches (der vom Restaurant erbt) ...
Nanu.. wo ist denn der ganze Thread abgelieben? Erst nach den ersten Postings wurde es doch so richtig.. ahm.. spannend :)
MfG
hi ;)
Naja, zumindest ist bei hotti "bestellen" eine Methode des Tisches (der vom Restaurant erbt) ...
Das ist schon ne Weile her, mittlerweile gab es ein paar Todesfälle unter den Einrichtungsgegenständen (z.T. auch Selbstmorde) und das bedeutet:
Die Erbfolge hat sich geändert. Hinzu kommt, dass ein paar von den Stühlen das Laufen gelernt und den Saustall verlassen haben.
Schönes Wochenende ;)
Hotti
hi,
Die Methode, einen Artikel in einen Einkaufskorb zu legen, gehört IMHO in die Warenkorb-Klasse und nicht in die Artikel-Klasse.
Ja, klar. Die Artikel-Klasse bedient sich dieser Methode (z.B. Delegation).
Hotti
Tach!
Die Methode, einen Artikel in einen Einkaufskorb zu legen, gehört IMHO in die Warenkorb-Klasse und nicht in die Artikel-Klasse.
Ja, klar. Die Artikel-Klasse bedient sich dieser Methode (z.B. Delegation).
Warum? In der realen Welt legt sich weder ein Artikel selbst in den Warenkorb, noch greift der Warenkorb ins Regal. Es gibt am Ende eine dritte Instanz, die einen Artikel nimmt und dem Warenkorb übergibt.
dedlfix.
hi,
Die Methode, einen Artikel in einen Einkaufskorb zu legen, gehört IMHO in die Warenkorb-Klasse und nicht in die Artikel-Klasse.
Ja, klar. Die Artikel-Klasse bedient sich dieser Methode (z.B. Delegation).Warum? In der realen Welt legt sich weder ein Artikel selbst in den Warenkorb, noch greift der Warenkorb ins Regal. Es gibt am Ende eine dritte Instanz, die einen Artikel nimmt und dem Warenkorb übergibt.
nicht: $warenKorb->put($warenRegal->getProductById(<prodID>);
???
stattdessen $user->putToWarenkorb(getProductById(<prodID>);
mit
class User {
private var $warenKorb = new Warenkorb();
public function putToWarenkorb($article) {
$this->warenKorb->put($article);
}
}
?
mfg
tami
Tach!
Die Methode, einen Artikel in einen Einkaufskorb zu legen, gehört IMHO in die Warenkorb-Klasse und nicht in die Artikel-Klasse.
Ja, klar. Die Artikel-Klasse bedient sich dieser Methode (z.B. Delegation).Warum? In der realen Welt legt sich weder ein Artikel selbst in den Warenkorb, noch greift der Warenkorb ins Regal. Es gibt am Ende eine dritte Instanz, die einen Artikel nimmt und dem Warenkorb übergibt.
nicht:
$warenKorb->put($warenRegal->getProductById(<prodID>);
???
Abgesehen davon, dass ich bei hotti nie so richtig weiß, ob er Fachbegriffe richtig verwendet oder sie nach Gutdünken verwendet, vor allem wenn er sie nur als Stichwortbrocken in die Runde wirft, sieht das bei ihm vielleicht eher so aus (die Initialisierung von $this->warenkorb mit einem Warenkorb-Objekt mal weggelassen):
class Artikel {
var $warenkorb;
function Kunde_will_haben() {
$this->warenkorb->add($this);
}
}
In deinem Codebeispiel hingegen wissen weder der Warenkorb noch das Regal zwangsläufig etwas voneinander. Die dritte Instanz ist hier der Code, der anzunehmenderweise im Kontext eines Kunden läuft.
Man kann hier nicht alle Einzelheiten mit der realen Welt vergleichen oder diese abbilden. Denn dann müsste man zum Beispiel das Äquivalent programmieren, das die gesamte Oberfläche eines Produkts absucht, um die Artikelnummer oder einen aufgedruckten Preis zu finden. Hier ist es zur Vereinfachung zulässig, wenn man allen Artikeln ein gemeinsames Merkmal in Form eines Interfaces (oder bei nicht sehr unterschiedlichem Warenbestand einer Basisklasse) mitgibt. Der Warenkorb ist bei strenger Typisierung also auch so implementiert, dass er nur Objekte mit diesem Interface (oder der Basisklasse) annimmt.
In der realen Welt sind derzeit die notwendigen technischen Voraussetzugen noch nicht implementiert, so dass der Warenkorb weder seinen Inhalt kennt, noch eine Summe der Preise bilden kann. Hier weicht die elektronische Welt vor und schafft sich ihre eigenen Beziehungen der Dinge untereinander. Diese sollten aber logisch sinnvoll aufgebaut sein.
stattdessen
$user->putToWarenkorb(getProductById(<prodID>);mit
class User {
private var $warenKorb = new Warenkorb();
public function putToWarenkorb($article) {
$this->warenKorb->put($article);
}
}
>
> ?
Unter der Annahme, dass deine "nicht"-Codezeile auch im Kontext eines Kunden läuft - der Warenkorb wird sicherlich nicht herrenlos programmiert sein -, sehe ich keinen grundlegenden Unterschied zur "stattdessen"-Variante.
dedlfix.
hi,
Abgesehen davon, dass ich bei hotti nie so richtig weiß, ob er Fachbegriffe richtig verwendet oder sie nach Gutdünken verwendet, vor allem wenn er sie nur als Stichwortbrocken in die Runde wirft,
Vermutlich kannst Du mit dem Stichwort 'Delegation' nichts anfangen.
Hotti
Tach!
Abgesehen davon, dass ich bei hotti nie so richtig weiß, ob er Fachbegriffe richtig verwendet oder sie nach Gutdünken verwendet, vor allem wenn er sie nur als Stichwortbrocken in die Runde wirft,
Vermutlich kannst Du mit dem Stichwort 'Delegation' nichts anfangen.
Vermutlich stelle ich mir darunter etwas anderes vor. Vor allem stelle ich mir andere Anwendungsfälle vor. Ich sehe keinen Grund, warum beim Hinzufügen eines Objekts zu einer Liste irgendetwas delegiert werden muss.
dedlfix.
Hi, jetzt wirds interessant ;)
Abgesehen davon, dass ich bei hotti nie so richtig weiß, ob er Fachbegriffe richtig verwendet oder sie nach Gutdünken verwendet, vor allem wenn er sie nur als Stichwortbrocken in die Runde wirft,
Vermutlich kannst Du mit dem Stichwort 'Delegation' nichts anfangen.Vermutlich stelle ich mir darunter etwas anderes vor. Vor allem stelle ich mir andere Anwendungsfälle vor. Ich sehe keinen Grund, warum beim Hinzufügen eines Objekts zu einer Liste irgendetwas delegiert werden muss.
Muss nicht, aber kann. Beispiel Artikelpräsentation (Responseklasse): Sowohl für die Präsentation (V View) als auch für das Hinzufügen (C Control) eines Artikels zum Warenkorb wird die Schnittstelle zu den Artikel-Objekten benötigt. Nennen wir die "Schnittstelle zu den Artikel-Objekten" class "AI" (Article Interface).
In der "Artikelpräsentation" (Responseclass "Manager::Article", Response-Objekt RO) gibt es die beiden Methoden browse() und control(). In beiden Methoden wird eine Instanz (Objekt) der Klasse AI benötigt.
Jetzt gibt es zwei Möglichkeiten:
1 jeweils in browse() und in control() wird ein AI-Objekt erstellt.
2 das AI-Objekt wird nur einmal erstellt.
Im Fall 2 kann das z.B. im Konstruktor gemacht werden, der über browse() und control() steht: Das AI-Objekt wird zum Attribut des RO gemacht. Einfache Delegation:
// methods in response class
function browse{
$article = $this->AI->fetch_object($artnr);
}
// $this->AI also available in function/method control()
Das Delegieren kann erweitert werden, dadurch dass die AI-Methode fetch_object() selbst als RO-Methode deklariert wird. Method fetch_object() kann dann direkt über das RO aufgerufen werden. Auch hier gibt es wieder zwei Möglichkeiten:
1 das AI-Objekt wird innerhalb der Responseklasse im Konstruktor zum Attribut des RO gemacht (wie oben beschrieben)
2 das AI-Objekt wird innerhalb der Methode fetch_object() erstellt
Im Fall 2 würde ich die Methode jedoch anders nennen, z.B. fetch_article(), also wenn diese Methode zur Responseklasse gehört, ansonsten führt das zu Missverständnissen.
Das Warenkorb-Interface wird nur in control() benötigt. Hier reicht eine einfache Objekterstellung.
Das AI ist bei mir über einen ORM-Layer realisiert ;)
Hotti
Tach!
Meiner Auffassung nach sind das ganz normale Methodenaufrufe, die du da beschreibst. Auch wenn es Methoden von anderen Objekten sind, zu denen du eine Referenz hast, wird das noch keine Delegation. Die fängt für mich erst da an, wo bei C# das Schlüsselwort delegate ins Spiel kommt.
dedlfix.
hi,
Meiner Auffassung nach sind das ganz normale Methodenaufrufe, die du da beschreibst. Auch wenn es Methoden von anderen Objekten sind, zu denen du eine Referenz hast, wird das noch keine Delegation. Die fängt für mich erst da an, wo bei C# das Schlüsselwort delegate ins Spiel kommt.
Gelegentlich wird die Delegation als Entwurfsmuster bezeichnet und ein Solches ist unabhängig von der Programmiersprache. PHP und Perl kennen kein Schlüsselwort 'delegate', das Delegieren von Methoden ist jedoch sowohl in PHP als auch in Perl möglich und oftmals gegenüber einer Vererbung die zweckmäßigere Lösung wenn es darum geht, Beziehungen zwischen Klassen herzustellen.
Zweckmäßigkeit:
-Vererbung macht Sinn, wenn alle Methoden der Basisklasse in der Subklasse gebraucht werden.
-Delegation macht Sinn, wenn nur eine überschaubare Anzahl an Methoden einer fremden Klasse in der eigenen Klasse gebraucht werden.
Praktisches Beispiel:
package Manager; # meine Basisklasse
require CGI;
# Konstruktor, meine Instanz bekommt als Attribut
# eine Instanz der Klasse CGI
sub new{
my $class = shift;
return eval{
bless{
CGI => new CGI,
# weitere eigene Attribute
};
};
}
# die Methode CGI::param wird delegiert
# in package Manager
sub param{
my $self = shift;
return $self->{CGI}->param(@_);
}
# damit kann die Instanz der Klasse Manager die param()-Methode
# wie gewohnt aufrufen
# diese Delegation funktioniert in PHP genauso
Hotti
Tach!
Meiner Auffassung nach sind das ganz normale Methodenaufrufe, die du da beschreibst. Auch wenn es Methoden von anderen Objekten sind, zu denen du eine Referenz hast, wird das noch keine Delegation.
Ich kann mich nur wiederholen. Der entscheidende Aspekt einer Delegation ist (laut Wikipedia und allen Beispielen, die ich außerdem dazu gefunden haben), dass die Bindung zwischen Aufrufer und dem Aufgerufenen erst zur Laufzeit hergestellt wird, sie damit variabel ist und nicht bereits fest im Code verankert ist. In deinem jetzigen Beispiel ist bereits im Code festgelegt, dass vom selbst erstellten CGI-Objekt und keinem anderen eine Methode aufgerufen wird. Eine Delegation wird es erst dann, wenn im Klassencode noch nicht ersichtlich ist, von welcher konkreten Instanz die Methode aufrufen wird.
Wenn man die Objektorientierung mal beiseite lässt, wäre nach deiner Auffassung jeder stinknormale Funktionsaufruf bereits eine Delegation. Eine dynamische Bindung kommt jedoch erst dann zustande, wenn die auszuführende Funktion zur Laufzeit bekanntgegeben wird. Bei Callbacks in PHP zum Beispiel bekommt der Aufrufer den Namen der aufzurufenden Funktion erst bei seinem Aufruf als Parameter übergeben. Somit kann die Bindung erst jetzt hergestellt und nicht gleich vom Bytecode-Compiler erzeugt werden.
Oder mit anderen Worten: Wenn ein Mitarbeiter fest angestellt ist, dann erledigt er zwar (Teil-)Aufgaben, ist aber trotzdem Teil des großen Ganzen namens Firma. Eine Delegation kommt zustande, wenn im laufenden Betrieb ein Externer hinzukommt, um eine Aufgabe zu erledigen.
dedlfix.
Hi,
-Vererbung macht Sinn, wenn alle Methoden der Basisklasse in der Subklasse gebraucht werden.
meiner Erfahrung nach ist dies nicht korrekt. Vererbung sollte eine "A ist ein B" oder (sogar besser) "A verhält sich wie B" ausdrücken.
Die Aussage "A benutzt B (vollständig)" ist nicht ausreichend. In diversen Büchern (*) wird explizit davor gewarnt, zu häufig Vererbung einzusetzen.
Bei deinem Beispiel frage ich mich, warum die Manager-Klasse überhaupt eine param-Methode hat. Warum bietet die Manager-Klasse etwas an, was die CGI-Klasse anbietet? Ich muss aber auch sagen, dass mir der Name "Manager" zu allgemein ist.
Als weiteren Verbesserungsvorschlag: warum instantiierst du CGI fest in deinem Konstruktor? Wäre es nicht besser, ein CGI-Objekt als externe Abhängigkeit reinzugeben? Das würde es dir erleichtern, Unit-Tests zu schreiben, da die Abhängigkeit vom CGI-Objekt dadurch klarer wird. Insbesonders, da das CGI-Objekt ja auf globale Status (Query-String, STDIN) zugreift.
*: ich habe hier z.B. Sutters, Alexandrescus "C++ Coding Standards" in der Hand. Hier heißt es in Regel 34: "If a relationship can be expressed in more than one way, use the weakest relationship that's practical. Given that inheritance is nearly the strongest relationship we can express in C++ [...], it's only really appropriate when there is no equivalent weaker alternative".
Bis die Tage,
Matti
Moin,
Bei deinem Beispiel frage ich mich, warum die Manager-Klasse überhaupt eine param-Methode hat. Warum bietet die Manager-Klasse etwas an, was die CGI-Klasse anbietet?
Im Allgemeinen kann das IMO schon sinnvoll sein, z.b. um die Schichten in einer Applikation voneinander zu trennen, und die konkrete Implementierung der darunter liegenden Klasse vor dem Rest der Applikation zu abstrahieren.
Konkret könnte ich mir bei dem Beispiel einen Manager vorstellen, der beliebige Parameter aus einem Input zurückgeben können soll. Der Manager soll aber nicht wissen, wie das Parsen der Parameter genau implementiert ist, da auf dieser Software-Schicht das Parsen selbst nicht mehr relevant ist - er soll vielmehr in der Lage sein, mittels IRGENDEINEM wie auch immer gearteten Parameter-Parser (in diesem Fall das CGI-Modul) Parameter zu ermitteln.
Ein anderer Parser könnte dann z.b. ein CSV-Parser sein, der die Parameter aus einem Flatfile liest, und auch dieser könnte durch den Manager genutzt werden (sofern er über eine "param"-Methode verfügt).
Vererbung (CGI->Manager) würde dann keinen Sinn machen (denn, wie Du richtig schreibst, müsste dann gelten "JEDER Manager IST ein CGI", was falsch ist (z.b. im Falle des CSV-Parsers).
Für diesen Fall ist es daher durchaus sinnvoll, den Manager als Proxy bzw. Adapter (oder wie auch immer man es bezeichnen will) zu implementieren, der den Aufruf "param" dann an den zuständigen Parser (z.b. CGI) deligiert.
Allerdings, wie dedlfix richtig schrieb: Der Hauptvorteil dieses Entwurfsmusters ist eigentlich, dass der Aufrufer (also hier Manager) die konkrete Implementierung nicht "kennen" muss, und somit komplett von ihr unabhängig ist (was späteres Austauschen der Implementierung wesentlich erleichert), weswegen die Verbindung zwischen Proxy und dem realen Objekt in der Regel auch immer erst zur Laufzeit erzeugt wird (z.b. mittels Dependency Injection.
Wird der CGI-Konstruktor hingegen direkt vom Manager aufgerufen, wie in dem Beispiel, so geht die Unabhängigkeit zwischen CGI und Manager verloren.
These were my 5 cents.
Viele Grüße,
Jörg
hi Jörg,
Wird der CGI-Konstruktor hingegen direkt vom Manager aufgerufen, wie in dem Beispiel, so geht die Unabhängigkeit zwischen CGI und Manager verloren.
Die Abhängigkeit beschränkt sich auf die Tatsache, dass ich CGI::param() brauche. Tatsächlich kann CGI::param() auch ohne CGI-Instanz aufgerufen werden, also ohne den Konstruktor der CGI-Klasse vorher bemühen zu müssen.
Das CGI-Objekt (Instanz erzeugt mit new CGI;) hat jedoch ein paar Methoden, die nur über das Objekt verfügbar sind, das betrifft insbesondere den Upload von Dateien über den Browser.
Hotti
hi Matti,
Bei deinem Beispiel frage ich mich, warum die Manager-Klasse überhaupt eine param-Methode hat. Warum bietet die Manager-Klasse etwas an, was die CGI-Klasse anbietet? Ich muss aber auch sagen, dass mir der Name "Manager" zu allgemein ist.
Der Name könnte auch 'Response' heißen, das ist in meinem FW die Basisklasse, die für jedem Request ein Responseobjekt (RO) erstellt. Jedes RO muss in der Lage sein, Parameter (GET, POST) verarbeiten zu können, das ist der Grund.
Der klassische Fall für eine Delegation: Gebraucht wird nur der Parser und anstatt einen eigenen Parser zu programmieren, wird die param()-Methode von Class CGI delegiert, von einer Klasse die sich jahrzehntelang bewährt hat.
--Hotti
Hi,
Bei deinem Beispiel frage ich mich, warum die Manager-Klasse überhaupt eine param-Methode hat. Warum bietet die Manager-Klasse etwas an, was die CGI-Klasse anbietet? Ich muss aber auch sagen, dass mir der Name "Manager" zu allgemein ist.
Der Name könnte auch 'Response' heißen, das ist in meinem FW die Basisklasse, die für jedem Request ein Responseobjekt (RO) erstellt. Jedes RO muss in der Lage sein, Parameter (GET, POST) verarbeiten zu können, das ist der Grund.
Warum muss denn ein Response-Objekt Parameter verarbeiten können. Ein Response hat meist (wenn ich mir gängige Framework-Lösungen ansehe) ebenjene Eigenschaften, die für einen HTTP-Response notwendig sind (HTTP-Header, Body).
Es ist nicht die Aufgabe des Response-Objekts, sich selbst zu erstellen, also muss das Response-Objekt auch keine Möglichkeiten haben, Parameter zu verarbeiten. Meist hat eine solche Rolle ein Controller, welcher ein Request-Objekt bekommt (und dieses bekommt einen Parameter-Parser übergeben bzw. kann Parameter parsen).
Der klassische Fall für eine Delegation: Gebraucht wird nur der Parser und anstatt einen eigenen Parser zu programmieren, wird die param()-Methode von Class CGI delegiert, von einer Klasse die sich jahrzehntelang bewährt hat.
Du könntest auch einen Parameter-Parser als externe Abhängigkeit an die Stelle übergeben, an der du sie brauchst. Notwendigkeit der Komposition/Delegation sehe ich da überhaupt nicht.
Bis die Tage,
Matti
hi,
Warum muss denn ein Response-Objekt Parameter verarbeiten können.
Nicht nur verarbeiten, auch prüfen, ob es Parameter gibt. In meinem FW wird bei JEDEM Request geprüft, ob es Parameter gibt.
Ein Response hat meist (wenn ich mir gängige Framework-Lösungen ansehe) ebenjene Eigenschaften, die für einen HTTP-Response notwendig sind (HTTP-Header, Body).
Und: Jeder Request kann Parameter enthalten. Jeder Request sendet auch HTTP-Header. In meinem FW kann jede Responseklasse Parameter verarbeiten. Oder den Content abhängig vom Request-Header aushandeln.
Es ist nicht die Aufgabe des Response-Objekts, sich selbst zu erstellen, also muss das Response-Objekt auch keine Möglichkeiten haben, Parameter zu verarbeiten.
Bedenke: Jeder Request kann Parameter enthalten.
Meist hat eine solche Rolle ein Controller, welcher ein Request-Objekt bekommt (und dieses bekommt einen Parameter-Parser übergeben bzw. kann Parameter parsen).
Dumme Frage: Woher will die Responseklasse wissen, dass der Controller aufgerufen werden soll? Klare Antwort: Das RO muss prüfen können, ob es Parameter gibt und das bei JEDEM Request. Das macht alles der Parser.
Du könntest auch einen Parameter-Parser als externe Abhängigkeit an die Stelle übergeben, an der du sie brauchst.
Jeder Request kann Parameter enthalten. Das zu prüfen, ist auch eine Aufgabe des Parsers, der Parser wird also bei jedem Request gebraucht.
In meinem FW kann jede Responseklasse ausführbaren Code enthalten.
Hotti
hi,
Die Methode, einen Artikel in einen Einkaufskorb zu legen, gehört IMHO in die Warenkorb-Klasse und nicht in die Artikel-Klasse.
Ja, klar. Die Artikel-Klasse bedient sich dieser Methode (z.B. Delegation).Warum? In der realen Welt legt sich weder ein Artikel selbst in den Warenkorb, noch greift der Warenkorb ins Regal. Es gibt am Ende eine dritte Instanz, die einen Artikel nimmt und dem Warenkorb übergibt.
Ja, klar, das macht der Kunde ;)
Hotti
Tach!
In der realen Welt legt sich weder ein Artikel selbst in den Warenkorb, noch greift der Warenkorb ins Regal. Es gibt am Ende eine dritte Instanz, die einen Artikel nimmt und dem Warenkorb übergibt.
Ja, klar, das macht der Kunde ;)
Na siehste, dann beschreib (und implementier) das doch auch so.
dedlfix.
Moin,
Ich habe lange Zeit in PHP "von Hand" programmiert, seit kurzem bin ich (auf Grund der positiven Erfahrungen, die ich mit dem Spring-Framework in Java gemacht habe) dabei, mich näher mit Symfony zu beschäftigen. In der Firma haben wir erfolgreich eine Applikation mit Symfony1 umgesetzt, privat arbeite ich gerade an einer Applikation mit Symfony2.
Frameworks haben natürlich immer das Problem, dass man am Anfang erstmal mit dem Framework selbst klar kommen muss, das ging mir bei Symfony nicht anders.
Für kleine Anwendungen mag sich das nicht rentieren.
Die Lernkurve ist aber sehr steil. Hat man einmal grob begriffen, wo alles ist, und wie man was macht, geht es recht fix, der Code wird sehr übersichtlich & kompakt, und die Aufwände für Anpassungen sind IMO deutlich geringer als bei einer komplett "hand-gestrickten" Applikation.
Vor allem muss man nicht zum hundert tausendsten mal so elementare (und gleichzeitig triviale) Sachen wie die Datenbank-Schicht neu erfinden (oder was selbst gestricktes wieder verwenden, was dann aber wieder genau für den Anwendungsfall nicht passt/funktioniert/umgebaut werden muss).
Für mich stellt sich das so dar, dass ich, wenn ich eine große PHP-Anwendung von Grund auf durch und durch sauber und performant programmieren möchte, ein paar Dinge auf jeden Fall brauche, z.b.
Dann kommen (nicht immer, aber oft) noch so Dinge wie Zugriffsschutz, sprechende URLs, Benutzerverwaltung usw. hinzu.
Wieso sollte ich mir das alles selbst programmieren, wenn Frameworks wie Symfony das "out-of-the-box" mitbringen?
Ich habe mir Symfony2 mal näher angeguckt. Ich sag mal, ich finde das ziemlich abtörnend mit der ganzen Konfiguration.
Eigentlich verfolgt Symfony (ähnlich wie Ruby on Rails, Django o.ä.) einen "Convention over Configuration"-Ansatz. Man muss eigentlich nur sehr wenig konfigurieren (konkret eigentlich nur die Datenbank-Connection ;) ), alles andere macht das Framework automatisch, es sei denn, Du legst es konkret darauf an, etwas anders machen zu wollen.
So long,
Jörg
Moin!
ich arbeite jetzt schon über 15 Jahre als Entwickler, aber so richtig warm bin ich mit PHP-Frameworks noch nie geworden. So richtig den Sinn habe ich davon auch noch nicht verstanden.
Und andere Programmiersprachen, die auch Frameworks haben?
wir arbeiten in unserer Firma in zwei Teams: wir, die einen, die "Alten", arbeiten eher agil, d.h. pures Coding, sicherlich viel Redundanz, sicherlich vieles Quick&Dirty, sicherlich vieles nur 95%, sicherlich vieles nicht für die Ewigkeit.
Das, was du beschreibst, klingt für mich aber eher nach "chaotisch", nicht "agil". Insbesondere "quick&dirty" beißt sich mit "agil" meiner Ansicht nach, denn damit man nachhaltig eine konstante Lieferleistung halten kann, darf man sich nicht immer tiefer in die Grütze reiten - und alle "dirty"-Lösungen reiten einen dort hinein, weswegen sie auch nur scheinbar "quick" sind.
Ich sage mal, wir sind extrem erfolgreich mit unserer Abteilung.
Funktioniert eure Software? Und kann man sie an neue Anforderungen anpassen? Wenn beides mit JA zu beantworten ist (das Auftreten von Bugs bedeuten NEIN), ist gegen das Resultat ja nichts einzuwenden.
Vor allem sind wir schnell.
Schnell im Vergleich zu wem? Und welche Voraussetzungen werden da verglichen?
Die andere Abteilung, die Jugend, nutzt das Zend-Framework bzw. Symfony2. Da dockerten jetzt 10 Leute an einer Applikation seit ca.1 Jahr rum, die die agile Abteilung in 4 Wochen geschrieben hätte.
Glaube ich nicht!
Hast du intensiven Einblick in die Anforderungen des Projekts? Kennst du den Kenntnisstand der Entwickler im Hinblick auf das eingesetzte Framework sowie die fachlichen Anforderungen? Kennst du die aktuelle Fehlerrate des Projekts, auch im Vergleich zu der deines eigenen Teams? Wieviele Leute sind eigentlich in diesem sogenannten "agilen Team"?
Vielleicht nicht so hübsch, aber dafür lauffähig.
Aussehen wird mitbewertet.
Vor allem schwächelt die Symfony2-App an jeder Ecke...
Inwiefern?
Ich habe mir Symfony2 mal näher angeguckt. Ich sag mal, ich finde das ziemlich abtörnend mit der ganzen Konfiguration. Sicherlich nette Aspekte dabei, aber den Hype dahinter verstehe ich nicht. Vielleicht bin ich zu alt.
Vermutlich. Denn es ist kein Hype. Frameworks bieten eine Lösung für die alltäglichen Programmieraufgaben, die man deshalb nicht mehr selbst lösen muss.
MVC - gelöst.
Formularvalidierung - gelöst.
Datenbankzugriff abstrahieren - gelöst.
...
Wenn man Probleme lösen muss, für die kein Framework etwas anbietet, und keine Probleme hat, für die ein Framework etwas anbietet, dann ist es natürlich sinnlos.
Im übrigen glaube ich nicht, dass du in deinem "agilen" Team ohne Framework arbeitest. Ich bin mir sicher, mindestens du persönlich hast im Laufe der Zeit eine Sammlung von Dateien und Code hergestellt, in der deine alltäglichen Probleme eine Lösung haben. Diese wirst du immer wieder einsetzen, sobald du auf ein passendes Problem stößt. Vermutlich wird sowas sogar das gesamte Team haben.
Voila: Dein eigenes Framework.
Der Vorteil so einer Konstruktion: Es löst die Dinge auf die für das Problem ideale Weise, und weil man es selbst entwickelt hat und den Source kennt und beliebig anpassen kann, ist es das flexibelste Framework auf der Welt für einen.
Der Nachteil: Für einen Neueinsteiger ist es absolut unverwendbar, weil es mutmaßlich keinerlei brauchbare Dokumentation gibt, außer er arbeitet sich intensiv ein und fragt seine Kollegen ständig Löcher in den Bauch.
Der Vorteil eines der standardisierten Frameworks: Eine riesige Community im Internet, zahlreiche Lösungen für Probleme, die andere schon mal hatten, sind googlebar, und Sicherheits-Updates werden selbstverständlich zeitnah veröffentlicht.
Ein gutes Framework ist darüber hinaus so modular, dass man ohne Probleme die relevanten Teile verwenden kann und die überflüssigen weglässt.
Ebenso gings mir mit Django, Cake, und noch ein paar anderen. Das einzige Framework, was ich wirklich nutze, ist Jmonkey. Aber das ist ne andere Baustelle.
Also, was haltet ihr von PHP-Frameworks? Nötig? Überbewertet? Unsinnig? Wer arbeitet damit?
Ich würde nicht ohne eines arbeiten wollen.
- Sven Rautenberg
Hallo zusammen,
das Thema interessiert mich auch schon lange.
Welches PHP Framework verwendet ihr?
Wie ist das Zend Studio?
Welche IDEs verwendet ihr?
vielen Dank und viele Grüße
hawk
hi,
zend-framework ist immer wieder mein tipp. vielleicht auch mal 2.0 anschauen.
mfg
tami
mein Senf:
also erstmal danke für deinen Post. Bei PHP habe ich bislang auch auf Frameworks verzichtet bzw. verwende mein eigenes. Die Frage die mich seit langem Quält ist die ob man heut zu Tage überhaupt noch einen Job bekommt, wenn man sich nicht in die Abhängikeit eines Frameworks begibt. Und da bist du ein gutes Beispiel für ein "ja".
Ein Framework ist auch immer gleichzeitig eine Abhängigkeit. Kann das Framework überhaupt das was ich brauche? Wenn ja, weiß ich das auch? Ein Framework ist nur so gut wie seine Dokumentation. Wenn die hälfte der Sachen nicht Dokumentiert ist...wer guckt sich schon den Quellcode an?
Auf der anderen Seite kann ein Framework die Arbeit wirklich erleichtern. Bin vor 4 Monaten etwa auf Jquery umgestiegen. Dass war wirklich ein Quantensprung! Problem ist eben, wenn man eine Anforderung an das Framework hat, welches es nicht unterstützt. Da sucht man erstmal stunden lang in der Doku um es am Ende doch selbst zu programmieren. Das betrifft auch viele Plugins. Deshalb war ich bislang angehalten die Sachen doch selbst zu bauen. Wenn man dann eine Konfiguration braucht ist die schneller erledigt. Auf der anderen Seite ist es sehr nervig ständig an Grundlegenden Sachen rum zu schreiben.
Gruß
Framing
T-Rex