Koala

na ja - mit zeitgemäß hat das nichts zu tun nikosch:
eine Website (deren Klassen) haben keine Methode driveForward(),
weder Controller, noch View oder Model.

Und auch keine Methode stopEngine() ...

__________________
Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

Mister Ad

Trainmaster

Ich finde es nicht verkehrt, Dinge wie Vererbung anhand eines solch allgemeinen Beispiels kurz und knackig zu erklären. Jedoch muss ich es nicht haben, dass dies im kompletten Verlauf eines Buches seinen Platz findet. Das ist meine persönliche Meinung.

Ein paar sinnvolle Gegenvorschläge möchte ich nennen: Benutzerverwaltung, Rechteverwaltung, Warenkorb-System, Kommentar-Funktion, Bewertungsfunktion, Oberfläche zur Verwaltung und Veröffentlichung von diversen Medien (Ton, Bild, Schrift) und viele weitere Dinge. Je nach Anforderung können diese Dinge komplexer oder trivial implementiert werden. Ich wage zu behaupten, dass diese Beispiele praxisnäher sind.

Eines möchte ich abschließend betonen: Meine Meinung bzgl. der Art der Beispiele hat keine nennenswerte negative Auswirkung auf das Verständnis. Mir geht es hier einzig um einen persönlich nicht zusagenden Stil der Auswahl von Beispielen.

nikosch

„zeitgemäß“ heißt nur der Thread, mir gings um meinen Beitrag. Und klar hat ein Controller kein Lenkrad, dafür weiß aber ein Einsteiger auch nichts mit dem Wort anzufangen, wenn ich in einem Lehrbuch von „Controllern“ fasele. Denn das Wort ist mannigfaltig in der Alltagssprache überladen, selbst in der IT ist der Begriff mehrdeutig. Eindeutig und verständlich zu sein ist aber das wichtigste an einem Lehrbuch.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

da_b0uncer

Ja, dem kann ich nur zustimmen.
Ich hab mich im Studium auch immer gefragt, ob die mich vorsätzlich verwirren wollen, mit dem ganzen Auto-Beispielen...

Am besten hab ich die ganzen Dinge verstanden, als ich Beispiele gesehen hab, die mit dem zutun hatten, wofür ich den Kram eigentlich gelernt hab.

Danach war's auch kein Problem mehr diese gelernten Dinge wo anders an zu wenden.

Gruber's Hans

Könntest du das wohl noch einmal kurz erläutern? Ist die Aussage allgemein, also das die Registry nie in der index.php initialisiert wird oder, dass die DI nicht über eine Registry sondern über den DIContainer als NamedService erfolgt?

Anyway, was wäre denn jetzt die best practice? Ich würde im Moment tatsächlich zum DIContainer tendieren.

dr.e.

Hallo Hans,

ich habe den Thread nicht mehr ganz in Erinnerung, aber meine Aussage bedeutet, dass DI nicht die Vorgehensweise ist, eine Komponente in der index.php in eine Registry zu schreiben und diese dann in einer Teil-Komponente zu nutzen. Also in etwas das NICHT:

index.php
NewsController.php
Dependency injection sollte IMHO transparent und mehrfach verwendbar sein. Deswegen sollte ein Service immer über einen DI-Container bezogen werden, der die Initialisierung vornimmt und die Abhängigkeiten des Services etc. auflöst. So kannst du eine Datenbank-Connection beispielsweise 2x konfigurieren, einmal für eine Komponente, einmal für eine andere. Weiterhin kannst du von aussen Steuern ob ein Service nun im DEBUG-Modus laufen soll oder nicht. Ist der Konfigurations-Mechanismus noch so intelligent, dass er zwischen verschiedenen Umgebungen unterscheiden kann, dann kannst du das sogar mit einem Satz an Konfigurationen abbilden (schau dir hierzu mal das Konfigurations-Schema des APF an).

Ein Beispiel für einen DI-Service und dessen Initialisierung findest du unter http://wiki.adventure-php-framework....ger#Einleitung Der DI-Container des APF setzt darauf, dass ein Service Namespace-, Context- und Umgebungs-abhängig konfiguriert werden kann.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~