Zitat:
Ich muss Toflar mal etwas verteidigen, da du hier etwas harsche argumente anbringst, die mMn auf einer fehlinterpretation Toflars post basieren.
Ich glaube du hast ebenfalls etwas fehlinterpretiert. Ich kritisiere Toflar in keinster Weise. Hier noch ein Zitat von Yannick aus dem IRC:
Zitat:
[16:13] <Toflar> mgco3: wieso verteidigt mich Oli im Thread? Du hast doch gar nix gegen mich gesagt, du hast ja nur meine Aussagen untermauert?
Natürlich mit dessen Einverständnis hier gepostet.
Zitat:
Semantisch ist das schon was anderes, das eine Beschreibt eine Datenbank-Spalte, das andere ein Eingabe-Widget. Beide haben durchaus ähnlich Eigenschaften.
Nein, es ist die Deklaration eines Objekt-Attributes. Was ich damit ausdrücken wollte; Das DCA lässt sich nicht eins zu eins in eine MVC-Umgebung implementieren, wohl aber bieten sich andere Wege an für diesen Aufbau die nicht mal sehr weit hergeholt sind.
Zitat:
Ich glaube du hast ihm hier nicht ganz verstanden. Er meint höchstwahrscheinlich, dass man eher auf MagicMethods zurückgreifen sollte um den Code etwas zu "verschlanken". Ich persönlich finde MagicMethods nicht besser, lieber 20 Setter/Getter, da man diese besser dokumentieren kann, durch autocompletition unterstützt werden und performanter sind.
Dann hat er sich leider etwas unglücklich ausgedrückt.
Symfony 1 erhielt jede Menge "Magie". Diese wurden in Symfony2 entfernt, sprich der Entwickler ist explizit gezwungen seine Getter/Setter sowie '"magicfinders" selbst zu schreiben. Dies hatte unter anderem damit zu tun, dass das ganze zu undurchschaubar wurde.
Auszug von der Symfony Live:
Zitat:
Q. "One of the main goals was to reduce the magic. I was in the training yesterday. $this->get('orm.entity_manager') returns something that is not typesafe. I have no idea what it is. It feels like magic. Are there plans to have convenience functions so I have interface-safe methods?"
A. "It's not about magic really, it's about scope. Killing the magic means everything is explicit. We don't use __get, __set. None of that in Symfony 2 because it is a nightmare to debug. When you get the service there is no typing because you can't know what class it is (because the point is to offer multiple implementations)." The controllers use ->get, nothing else has to (?). (Some of this involves issues I haven't really made contact with yet)
Q. "One of the main goals was to reduce the magic. I was in the training yesterday. $this->get('orm.entity_manager') returns something that is not typesafe. I have no idea what it is. It feels like magic. Are there plans to have convenience functions so I have interface-safe methods?"
A. "It's not about magic really, it's about scope. Killing the magic means everything is explicit. We don't use __get, __set. None of that in Symfony 2 because it is a nightmare to debug. When you get the service there is no typing because you can't know what class it is (because the point is to offer multiple implementations)." The controllers use ->get, nothing else has to (?). (Some of this involves issues I haven't really made contact with yet)
Zitat:
Totschläger Argument, das lediglich den zitierten Autor denunziert. Um das zu ändern, bitte noch folgende Fragen dazu mit beantworten:
Mit welchen Tools lässt du den Code denn generieren? (Btw. mein Tool heißt STRG-C, STRG-V ) Welche konkreten Bestandteile einer Klasse lässt du genieren? Hast du schon eine Contao-Extension veröffentlicht, wo man sich solch produzierten Code mal anschauen kann?
Dies war ganz klar auf die Aussage "Der Redundante Code den ich selbst bei top aktuellen Frameworks wie Symfony 2 sehe (getter und setter für jede einzelne Eigenschaft eines Models) brauchen nicht nur Zeit in der Entwicklung, sondern müssen bei Aktualisierungen dann auch an X Stellen angepasst werden." bezogen.
Man kommt in der Objektorientierten Entwicklung nie umher getter und setter anzupassen oder zu ergänzen. Das DoctrineBundle bietet einem hierzu einige Shell-Tools zur Vereinfachung an (https://github.com/symfony/symfony/b...ineCommand.php). Dies meinte ich mit generieren.
Bei symfony1 unterschied sich das, da über das schema.yml Baseklassen erstellt wurden, die erwähnte Funktionalität beinhalteten. Hier nachzulesen: http://www.symfony-project.org/gentl...Layer-Doctrine und man seine Klassen dann davon abgeleitet hat.
Meine Aussage galt lediglich für symfony und nicht für Contao.