Zentrales ZF2 Verzeichnis

[bodo92]

Hallo zusammen,

ich fange jetzt an meine erste Anwendung mit ZF2 zu erstellen.
Hierzu habe ich mir die https://github.com/zendframework/ZendSkeletonApplication geladen und mit Composer das Framework nachgeladen.

Da auf dem Server zukünftig mehrere Anwendungen laufen werden dachte ich mir das ich das Framework in ein zentrales Verzeichnis packe und dann symbolische Links aus jedem Projekt erstelle die auf das Framework zeigen.

Dazu habe folgende Fragen:
Gibt es hierfür bessere Lösungen um das Framework zentral für mehrere Anwendungen bereitzustellen oder ist das überhaupt nicht zu empfehlen, würde dadurch die Performance merklich leiden.

 

[scbawik]

Hallo zusammen,

ich fange jetzt an meine erste Anwendung mit ZF2 zu erstellen.
Hierzu habe ich mir die https://github.com/zendframework/ZendSkeletonApplication geladen und mit Composer das Framework nachgeladen.

Da auf dem Server zukünftig mehrere Anwendungen laufen werden dachte ich mir das ich das Framework in ein zentrales Verzeichnis packe und dann symbolische Links aus jedem Projekt erstelle die auf das Framework zeigen.

Dazu habe folgende Fragen:
Gibt es hierfür bessere Lösungen um das Framework zentral für mehrere Anwendungen bereitzustellen oder ist das überhaupt nicht zu empfehlen, würde dadurch die Performance merklich leiden.

Ich arbeite zwar nicht mit ZF (sondern Symfony) aber was verstehst du überhaupt unter "mehrere Anwendungen"?
Haben diese "Anwendungen" überhaupt miteinander etwas zu tun?
Ein Framework ist nämlich die Basis einer Anwendung.
Nicht jedoch ein Betriebssystem auf dem mehrere Anwendungen laufen.

So wie du es beschreibst klingt es so als ob du das Framework global installieren und dann deine Anwendungen darauf laufen zu lassen willst.

 

[bodo92]

Ja ich hatte vor das eben die Klassen des Frameworks für mehrere unabhängig voneinander laufenden Anwendungen zur Verfügung stehen.

 

[Tronjer]

Ich arbeite zwar nicht mit PHP, aber die Library auszugliedern, damit mehrere Anwendungen darauf zugreifen können, macht durchaus Sinn.

 

[scbawik]

Ja ich hatte vor das eben die Klassen des Frameworks für mehrere unabhängig voneinander laufenden Anwendungen zur Verfügung stehen.

Das macht für mein Verständnis keinen Sinn.
Das würde nur zu Inkompatibilitäten (Library-Versionen) führen.

Genau dafür gibt es ja den Dependency Manager Composer.
Dieser sorgt dafür dass jede Anwendung mit ausschließlich kompatiblen Dependencies versorgt wird.

 

[B3nnoX]

@scbawik
Also wenn ich dich nun richtig verstehe würdest du die Core Dateien vom Zend Framework 4 oder 5 mal hochladen, wenn du auf einem Server 4-5 Zend Framework Projekte erstellst?

Auf der einen Seite versteh ich es, weil die Anwendungen miteinander ja nicht wirklich was zu tun haben, auf der anderen Seite widerspricht es in mir auch irgendwie dann 4-5 die core Daten hochzuladen. Aber ich arebite nicht mit dem ZF, also weiß ich nicht ob es möglich wäre. Aber so wie ich es mal gelesen habe, sollte jedes Modul so konzipiert sein, dass es für sich alleine steht. Also ich denke es wäre möglich, wie weiß ich nun aber nicht.

 

[scbawik]

@scbawik
Also wenn ich dich nun richtig verstehe würdest du die Core Dateien vom Zend Framework 4 oder 5 mal hochladen, wenn du auf einem Server 4-5 Zend Framework Projekte erstellst?

Ja. 5 ZF Projekte bedeutet 5 eigenständige Anwendungen.
5 Anwendungen bedeutet (möglicherweise) 5x Unterschiedliche Anforderungen an Libraries.
Jede Anwendung muss für sich alleine funktionieren.

Auf der einen Seite versteh ich es, weil die Anwendungen miteinander ja nicht wirklich was zu tun haben, auf der anderen Seite widerspricht es in mir auch irgendwie dann 4-5 die core Daten hochzuladen. Aber ich arebite nicht mit dem ZF, also weiß ich nicht ob es möglich wäre. Aber so wie ich es mal gelesen habe, sollte jedes Modul so konzipiert sein, dass es für sich alleine steht. Also ich denke es wäre möglich, wie weiß ich nun aber nicht.

Hier geht es eben um den Unterschied von Anwendung/Framework und Modul/Komponente.

Die Anwendung (welche aus dem Framework entsteht) ist das Ganze.
Ein Modul/Eine Komponente ist hingegen ein Teil der Anwendung.
Diese "Teile" können natürlich in anderen Anwendungen auch verwendet werden da sie - wie du richtig sagst - unabhängig konzipiert werden.

Es werden jedoch nie zwei Anwendungen "ineinander programmiert".
Ich weiß leider nicht wie ich das gerade ausdrücken soll.

Jedenfalls: Großes Framework -> viel Speicherplatz.
Die Redundanz der Dateien ist egal, da wie gesagt Composer das Management übernimmt und so keine Probleme bezüglich Versionen auftauchen können.

 

[pax]

Ich kenne das ZendFramework auch nicht, aber ich arbeite viel mit CakePHP. Und dort ist es absolut üblich und gewollt, den Core nur einmal zu haben und auf dessen Basis beliebig viele Apps laufen zu lassen. Ich halte es für sehr wahrscheinlich, dass es im ZF genauso ist. Grundsätzlich ist eine Frameworkstruktur ja immer so aufgebaut, dass App-Klassen von Core-Klassen erben und dadurch die Frameworkfunktionen zur Verfügung stehen. Wie viele Klassen erben ist dem Core egal.

 

[bodo92]

Danke für eure Antworten, ich werde es jetzt so machen das ich es vorerst auf traditionelle Art mache. Also werde ich unter /var/www/<domain>/ die gesamte Anwendung einstellen und im Apache den Document-Root auf /var/www/<domain>/public setzen..

Eventuell kommen ja noch Vor- und Nachteile zum Thema dazu..

 

[scbawik]

Ich kenne das ZendFramework auch nicht, aber ich arbeite viel mit CakePHP. Und dort ist es absolut üblich und gewollt, den Core nur einmal zu haben und auf dessen Basis beliebig viele Apps laufen zu lassen. Ich halte es für sehr wahrscheinlich, dass es im ZF genauso ist. Grundsätzlich ist eine Frameworkstruktur ja immer so aufgebaut, dass App-Klassen von Core-Klassen erben und dadurch die Frameworkfunktionen zur Verfügung stehen. Wie viele Klassen erben ist dem Core egal.

Ja, genau.
Diese "Apps" sind jedoch nur Komponenten der Applikation, keine vollwertigen Standalone-Programme.

Und diese "Komponenten" werden in jeder Framework-Adaption einzeln inkludiert und nicht zwischen den Installationen freigegeben/global auf dem Server verfügbar gemacht.

 

[pax]

Diese "Apps" sind jedoch nur Komponenten der Applikation, keine vollwertigen Standalone-Programme.

Das stimmt nicht. Es kann sich um völlig verschiedene Anwendungen handeln. Sie müssen lediglich auf dem gleichen Server liegen. Cake ist so gebaut, dass man jede Configdatei und wenn es sein muss sogar eine Core-Klasse innerhalb der App überschreiben und damit anpassen kann ohne dass das den eigentlichen Core beeinflusst.

Sie sind insofern nicht "Standalone", dass sie natürlich den Link zum Core brauchen, aber ob der jetzt in mehrfacher Ausfertigung einzeln in jeder App liegt oder einmal zentral ändert daran nichts. Zentral vereinfacht jedenfalls das Updaten und loggen. Außerdem macht es die Struktur deutlich übersichtlicher.

 

[scbawik]

Das stimmt nicht. Es kann sich um völlig verschiedene Anwendungen handeln. Sie müssen lediglich auf dem gleichen Server liegen. Cake ist so gebaut, dass man jede Configdatei und wenn es sein muss sogar eine Core-Klasse innerhalb der App überschreiben und damit anpassen kann ohne dass das den eigentlichen Core beeinflusst.

Sie sind insofern nicht "Standalone", dass sie natürlich den Link zum Core brauchen, aber ob der jetzt in mehrfacher Ausfertigung einzeln in jeder App liegt oder einmal zentral ändert daran nichts. Zentral vereinfacht jedenfalls das Updaten und loggen. Außerdem macht es die Struktur deutlich übersichtlicher.

Ich glaube letztlich meinen wir das gleiche...

Habe es so verstanden:
Mehrere unabhängige "Anwendungen" (zB www.firma1.com, www.firma2.com).
Diese würden keine Scripts teilen, auch wenn sie auf dem selben Framework basieren und dem selben Server liegen.
Jede "Anwendung" hätte somit ihren eigenen Update-Zyklus.

Das was du als Apps bezeichnest, sind für mich Komponenten die als gesamtes die Anwendung bilden.