Guten Tag
Ich wollt nur mal die vielen OOP PHP User fragen: hat wer schon mal (egal ob aus interesse oder produktiv) eine Enterprise Architektur aufgezogen in PHP?
Ob App-Server Hin oder Her ist ja eigentlich egal. Mir gehts nur darum wie sich PHP mit vielen Instanzen, schichten, ... verhält.
Eigentlich sollte das neue MySQL 5.0 ja theoretisch in der Lage sein, als Datenbank für Enterprise Applikationen eingesetzt zu werden (nicht von der Stabilität sondern vom Funktionsumfang her).
Andererseitz bietet PHP noch keinen vernünftigen DAL -> kann man ja selbst implementieren. Von dort aus kommt man beliebig weiter nach oben.
Hat das schon mal wer probiert? Wie verhält sich denn PHP wenn da für einen Request recht viele Objekte instanziert werden müssen? Wie verhält sich das ganze, wenn man einen Code-Cache einsetzt?
Mal davon abgesehen dass PHP kein brauchbaren App-Server bietet und man im DAL wohl n bisschen handgebastel benötigt wäre alles da. Wenn man sich überlegt, was die Vorteile wären...
Bitte um Erfahrungsberichte.
Gruss
Enterprise Architektur in PHP
gepostet vor 18 Jahre, 9 Monate von schokofreak
gepostet vor 18 Jahre, 9 Monate von TheUndeadable
> Wie verhält sich denn PHP wenn da für einen Request recht viele Objekte instanziert werden müssen?
Ich kann nur für Zeiten aus PHP 4 reden. Dort hatten wir ein CMS mit einer Datenbank, einer Datenaufbereitungs- und einer Anzeigeschicht aufgebaut. Jeder Request hat etwa 150 Objekte initiiert, die sich gegenseitig mehr oder weniger referenziert hatte.
Das Ergebnis siehst du unter http://www.krautzberger.com/nostats/mttop.htx/de/nostats/products/top.htx/de/10cd53c333861169d1 . Ist etwa 3 Jahre alt.
Ich kann nur für Zeiten aus PHP 4 reden. Dort hatten wir ein CMS mit einer Datenbank, einer Datenaufbereitungs- und einer Anzeigeschicht aufgebaut. Jeder Request hat etwa 150 Objekte initiiert, die sich gegenseitig mehr oder weniger referenziert hatte.
Das Ergebnis siehst du unter http://www.krautzberger.com/nostats/mttop.htx/de/nostats/products/top.htx/de/10cd53c333861169d1 . Ist etwa 3 Jahre alt.
gepostet vor 18 Jahre, 9 Monate von schokofreak
Naja, zum Ankucken ist das schön - hast du Informationen zur Rechenzeit / Speicherverbrauch?
Und denk mal daran, wenn jede Entität in ner Struktur / nem Objekt gespeichert wird... könnte es da bedeutend mehr als 150 Objekte geben.
Gruss
Und denk mal daran, wenn jede Entität in ner Struktur / nem Objekt gespeichert wird... könnte es da bedeutend mehr als 150 Objekte geben.
Gruss
gepostet vor 18 Jahre, 9 Monate von Kampfhoernchen
Das instanziieren geht in PHP recht fix, wenn Konstruktoren vorhanden sind (diese unbedingt anlegen, auch wenn sie dann leer sind). 150 Objekte sind für eine Seite noch kein Problem, kritisch wirds erst so ab 500 (wie ich neulich mal feststellen musste). War aber noch zu PHP4 Zeiten, in PHP5 soll sich dass ja weiter verbessert haben.
gepostet vor 18 Jahre, 9 Monate von schokofreak
Hmmm... tönt so als gäbe es noch nicht viele leute, welche OOP im grossen Stile einsetzen
Wenns in PHP4 erst bei so ca. 500 Objekten kritisch wird, sollt das ganze kein Problem darstellen - denn man kann das ganze ja auch wieder optimieren sodass möglichst wenige Objekte benötigt werden - denk ich mal.
Eigentlich siehts so aus, als brächte es mal ne Referenz-Architektur für das ganze. Hat wer schon sowas? Ansonsten wärs glaub an mir, da mal was zu tippen.
Ach eigentlich bringts das auch ned... schlussendlich interessiert sich doch kein schwein dafür und kuckt es an...
Gruss
Wenns in PHP4 erst bei so ca. 500 Objekten kritisch wird, sollt das ganze kein Problem darstellen - denn man kann das ganze ja auch wieder optimieren sodass möglichst wenige Objekte benötigt werden - denk ich mal.
Eigentlich siehts so aus, als brächte es mal ne Referenz-Architektur für das ganze. Hat wer schon sowas? Ansonsten wärs glaub an mir, da mal was zu tippen.
Ach eigentlich bringts das auch ned... schlussendlich interessiert sich doch kein schwein dafür und kuckt es an...
Gruss
gepostet vor 18 Jahre, 9 Monate von Mudder
Also im grossen Stiel würde ich bei mir wirklich nicht sagen!
Ich verwende zwar Klassen und lasse Grossteile der Verarbeitungsfunktionen eines Projekts dort ablaufen. Doch spätestens wenns dann um Vererbung und Co geht bin ich raus - was wohl auch primär daran liegt, dass ich noch immer nicht mit PHP5 arbeite.
Was würdest du denn jetzt unter "grossem Stiel" verstehen und wie sähe ein PHP! Projekt entsprechend aus?
Ich verwende zwar Klassen und lasse Grossteile der Verarbeitungsfunktionen eines Projekts dort ablaufen. Doch spätestens wenns dann um Vererbung und Co geht bin ich raus - was wohl auch primär daran liegt, dass ich noch immer nicht mit PHP5 arbeite.
Was würdest du denn jetzt unter "grossem Stiel" verstehen und wie sähe ein PHP! Projekt entsprechend aus?
gepostet vor 18 Jahre, 9 Monate von schokofreak
Unter grossem Stil versteh ich folgendes:
Zugriff auf Datenbank via Stored Procedures
Pro Table/View gibt es eine CRUD-Klasse (Create Retreive Update Delete). Diese beitet dir Atomare DB Zugriffsmöglichkeiten.
Sämtliche Records werden als Entitäten gespeichert; da PHP nicht gut skaliert ev. Sets als ein Objekt
Business-Objekte bieten dir sämtliche verfügbare Funktionalität. Sprich mapping zu CRUD sowie Aufruf von speziellen StoredProcedures (wie Login).
Damit hat man ne Objektorientierte API auf die DB.
Codeumfang ist minimal... leicht (ab) tipparbeit, liesse sich allerdings generieren.
Darüber kommt ein Input-Handler, welcher pro möglichem Request die Daten inerpretiert. Diese an einen Workflow geben.
Der Workflow (beispielsweise "Benutzer Registrieren") führt die einzelnen Teilfunktionen direkt in oben benanntem API durch... Als rückgabewert füllt er entweder n Template aus oder gibt über ne bekannte Schnittstelle die Daten zu einer externen View-Komponente.
Das ist im prinzip ne klassische Enterprise-Architektur. Einfach angepasst auf die Bedürfnisse, sodass kein Overhead entsteht.
Der Vorteil darin ist, dass die Code-Komplexität auf jeder Schicht minimal ist. Zusätzlich lassen sich sämtliche Schichten bis zum Workflow generieren (wenn man mal ne Architektur definiert hat).
Was bedeutet das?
- Wenig Fehlerquellen
- Maximale Skalierbarkeit
- Maximale Sicherheit
- Schnelle und einfache Anpassbarkeit
Vergleich es damit, wie man normalerweise unter Java oder .Net eine Webapplikation entwickelt - ausser dass dort oft noch 1, 2 Zusätzliche Schnittstellen eingebaut werden.
Gruss
Zugriff auf Datenbank via Stored Procedures
Pro Table/View gibt es eine CRUD-Klasse (Create Retreive Update Delete). Diese beitet dir Atomare DB Zugriffsmöglichkeiten.
Sämtliche Records werden als Entitäten gespeichert; da PHP nicht gut skaliert ev. Sets als ein Objekt
Business-Objekte bieten dir sämtliche verfügbare Funktionalität. Sprich mapping zu CRUD sowie Aufruf von speziellen StoredProcedures (wie Login).
Damit hat man ne Objektorientierte API auf die DB.
Codeumfang ist minimal... leicht (ab) tipparbeit, liesse sich allerdings generieren.
Darüber kommt ein Input-Handler, welcher pro möglichem Request die Daten inerpretiert. Diese an einen Workflow geben.
Der Workflow (beispielsweise "Benutzer Registrieren") führt die einzelnen Teilfunktionen direkt in oben benanntem API durch... Als rückgabewert füllt er entweder n Template aus oder gibt über ne bekannte Schnittstelle die Daten zu einer externen View-Komponente.
Das ist im prinzip ne klassische Enterprise-Architektur. Einfach angepasst auf die Bedürfnisse, sodass kein Overhead entsteht.
Der Vorteil darin ist, dass die Code-Komplexität auf jeder Schicht minimal ist. Zusätzlich lassen sich sämtliche Schichten bis zum Workflow generieren (wenn man mal ne Architektur definiert hat).
Was bedeutet das?
- Wenig Fehlerquellen
- Maximale Skalierbarkeit
- Maximale Sicherheit
- Schnelle und einfache Anpassbarkeit
Vergleich es damit, wie man normalerweise unter Java oder .Net eine Webapplikation entwickelt - ausser dass dort oft noch 1, 2 Zusätzliche Schnittstellen eingebaut werden.
Gruss
gepostet vor 18 Jahre, 9 Monate von Krisch
Also das hört sich für mich stark nach einem MVC-Framework an, ausser dass du noch eine zusätzliche Datenbankschnittstelle einbaust. Wobei der Sinn der CRUD-Klasse in einer MVC-Anwendung eher fragwürdig ist, weil man dann besser eine neue Model-Klasse erstellt und dabei auch gleich Optimierungen vornehmen kann.
Aber eigentlich willst du ja nur wissen, was passiert wenn man in PHP viele Objekte verwendet, oder?
Besonders Model 2 ist empfehlenswert:
MVC Kurz & Gut
Aber eigentlich willst du ja nur wissen, was passiert wenn man in PHP viele Objekte verwendet, oder?
Besonders Model 2 ist empfehlenswert:
MVC Kurz & Gut
gepostet vor 18 Jahre, 9 Monate von schokofreak
Nein es ist gar nicht MvC. Das entscheidende ist das:
- Sämtliche Rechenlogik in der DB
- Objektorientierter Zugriff auf DB
- Workflow innerhalb Applikation
- Darüber dann ne ev. MvC ähnliche darstellung.
Stell dir vor, du kannst nun zwischen jeder einzelnen SChicht eine Netzwerk-Schnittstelle einbauen. Sprich die Skalierung stellt praktisch kein Problem mehr dar.
Zusätzlich kannst du von jeder Schicht mehrere Instanzen haben. Also Rechner 1 und Rechner 2 machen SChicht XY.
Auch DAS ist ein gewaltiger Vorteil.
Schlussendllich der wichtigste Vorteil. Bis hin zum Workflow kannst du alles generieren lassen. Das GUI kannst du dir, bei geeignetem generator, auch generieren lassen. Will so viel heissen wie: Du must nicht mehr programmieren - du must Designen.
Was die konsequenz hat, dass du bei einer Änderung der Logik genau nur die Logik anpasst - aber nciht wirklich programmierst.
MvC ist was ganz anderes, kleineres. Und n MvC alleine macht in meinen Augen in einer WebApplikation keinen Sinn.
Die frage ist nun eigentlich genau die: Solche Architekturen sind für persistente Server ausgelegt -> Applikationsserver.
Wie verhält sich sowas auf einem nciht persistenten Server wie PHP. Noch vielwichtiger: Kommt PHP überhaupt mit den Anforderungen klar?
Gruss
- Sämtliche Rechenlogik in der DB
- Objektorientierter Zugriff auf DB
- Workflow innerhalb Applikation
- Darüber dann ne ev. MvC ähnliche darstellung.
Stell dir vor, du kannst nun zwischen jeder einzelnen SChicht eine Netzwerk-Schnittstelle einbauen. Sprich die Skalierung stellt praktisch kein Problem mehr dar.
Zusätzlich kannst du von jeder Schicht mehrere Instanzen haben. Also Rechner 1 und Rechner 2 machen SChicht XY.
Auch DAS ist ein gewaltiger Vorteil.
Schlussendllich der wichtigste Vorteil. Bis hin zum Workflow kannst du alles generieren lassen. Das GUI kannst du dir, bei geeignetem generator, auch generieren lassen. Will so viel heissen wie: Du must nicht mehr programmieren - du must Designen.
Was die konsequenz hat, dass du bei einer Änderung der Logik genau nur die Logik anpasst - aber nciht wirklich programmierst.
MvC ist was ganz anderes, kleineres. Und n MvC alleine macht in meinen Augen in einer WebApplikation keinen Sinn.
Die frage ist nun eigentlich genau die: Solche Architekturen sind für persistente Server ausgelegt -> Applikationsserver.
Wie verhält sich sowas auf einem nciht persistenten Server wie PHP. Noch vielwichtiger: Kommt PHP überhaupt mit den Anforderungen klar?
Gruss
gepostet vor 18 Jahre, 9 Monate von Krisch
Jetzt hab ich's auch verstanden.
gepostet vor 18 Jahre, 9 Monate von Kampfhoernchen
Hier mal meine Architektur (vom Client zur Datenbank)
Templatesystem / Ajax
Sitehandler -> Basic Includes
Module
Datenzugriffs-Klassen / Helper-Klassen
(SQL-Helper)
Datenbank / Dateitreiber
Ein Modul ist eine Klasse mit 4 Funktionen:
requires() //Liste der Benötigten Klassen
access_check() // Darf der User dieses Modul sehen?
perform() //Operationen, die Ausgeführt werden
display() //Die Ausgabe des Moduls
und wird vom Sitehandler entsprechend verwaltet (Wiederverwendbarkeit)
Der Zugriff auf die Datenbank erfolgt ausschließlich über die Datenzugriffsklassen.
Helper Klassen sind keine echten Datenobjekte, werden aber für den Betrieb benötigt (u.a. Session, Sprachdateien, Template-Treiber, Remote-Klasse (zur Verarbeitung von Daten, die von "draußen" kommen), RegExen, ...)
Für den Aufbau einer Seite werden so zwischen 15 und 50 Klassen benötigt, performancemäßig gibs keine Probleme.
Das ganze ist nicht ganz die typische Enterprise-Architektur, wie man sie aus Java und Co. kennt. Aber für PHP / allgemein Webservices besser geeignet, wenn ich mich fragt.
Templatesystem / Ajax
Sitehandler -> Basic Includes
Module
Datenzugriffs-Klassen / Helper-Klassen
(SQL-Helper)
Datenbank / Dateitreiber
Ein Modul ist eine Klasse mit 4 Funktionen:
requires() //Liste der Benötigten Klassen
access_check() // Darf der User dieses Modul sehen?
perform() //Operationen, die Ausgeführt werden
display() //Die Ausgabe des Moduls
und wird vom Sitehandler entsprechend verwaltet (Wiederverwendbarkeit)
Der Zugriff auf die Datenbank erfolgt ausschließlich über die Datenzugriffsklassen.
Helper Klassen sind keine echten Datenobjekte, werden aber für den Betrieb benötigt (u.a. Session, Sprachdateien, Template-Treiber, Remote-Klasse (zur Verarbeitung von Daten, die von "draußen" kommen), RegExen, ...)
Für den Aufbau einer Seite werden so zwischen 15 und 50 Klassen benötigt, performancemäßig gibs keine Probleme.
Das ganze ist nicht ganz die typische Enterprise-Architektur, wie man sie aus Java und Co. kennt. Aber für PHP / allgemein Webservices besser geeignet, wenn ich mich fragt.
gepostet vor 18 Jahre, 9 Monate von Godfather
Hallo Freunde der schnellen Frameworks,
meine Name ist Bully aber das machts nichts.
Ich stehe hier mit meinem PHPEditor vor meiner Tapete, und das ist gut so. (ich hab zuviel Bully und die Tapete geschaut ).
Spass bei Seite:
Ich bin hier im Forum derzeit etwas inaktiv, da ich mich gerade auch mit Frameworks in PHP beschäftige. Ziel ist es ein von Java übertragendes Framework in PHP umzusetzen und das ist gar nicht so einfach, wie ich festgestellt habe.
Da ich hier selber noch am planen und überdenken des ganzen bin, dachte ich, ich schau mal ins Forum und da sehe ich diese Disskussion.
Möchte euch mal folgende URL mitteilen:
java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
Diese habe ic auch erst vor kurzem gefunden (und bin noch dabei es zu verstehen), und zeigt die Abläufe eines Request oder Abläufe insgesamt.
Vielleicht hilft es ja euch in euren überlegungen.
Mfg
meine Name ist Bully aber das machts nichts.
Ich stehe hier mit meinem PHPEditor vor meiner Tapete, und das ist gut so. (ich hab zuviel Bully und die Tapete geschaut ).
Spass bei Seite:
Ich bin hier im Forum derzeit etwas inaktiv, da ich mich gerade auch mit Frameworks in PHP beschäftige. Ziel ist es ein von Java übertragendes Framework in PHP umzusetzen und das ist gar nicht so einfach, wie ich festgestellt habe.
Da ich hier selber noch am planen und überdenken des ganzen bin, dachte ich, ich schau mal ins Forum und da sehe ich diese Disskussion.
Möchte euch mal folgende URL mitteilen:
java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
Diese habe ic auch erst vor kurzem gefunden (und bin noch dabei es zu verstehen), und zeigt die Abläufe eines Request oder Abläufe insgesamt.
Vielleicht hilft es ja euch in euren überlegungen.
Mfg
gepostet vor 18 Jahre, 9 Monate von Kampfhoernchen
Ich habs jetzt nur überflogen, aber das entspricht so ziemlich genau dem, was einsetze. Nur dass ich nicht reiin Objektorientiert, sondern eher Aspektorientiert arbeite (bis vor ein ein paar Tagen und einem Artikel in nem Java Magazin wusste ich das noch gar nicht).
gepostet vor 18 Jahre, 9 Monate von Macavity
und für diejenigen die das fragliche Magazin nicht gelesen haben.... was ist Aspektorientiert?
gepostet vor 18 Jahre, 9 Monate von Kampfhoernchen
gepostet vor 18 Jahre, 9 Monate von schokofreak
Fazit: Mit PHP & MySQL der neuesten Versionen lässt sich keine Enterprise- Architektur aufbauen.
Wieso? MySQL bietet zur Zeit (Version 5.1) immer noch keine benötigten Funktionalitäten. Beispielsweise ist es nicht möglich, Parametrisierte Views zu erstellen resp. aus Funktionen / Prozeduren Views als Rückgabewerte auszugeben.
Wann wird MySQL endlich zur Datenbank???
Gruss
Wieso? MySQL bietet zur Zeit (Version 5.1) immer noch keine benötigten Funktionalitäten. Beispielsweise ist es nicht möglich, Parametrisierte Views zu erstellen resp. aus Funktionen / Prozeduren Views als Rückgabewerte auszugeben.
Wann wird MySQL endlich zur Datenbank???
Gruss
gepostet vor 18 Jahre, 9 Monate von Feagor
Original von schokofreak
Wann wird MySQL endlich zur Datenbank???
Was ist stattdessen die beste möglichst kostenlos einsetzbare Datenbank der Wahl, wenns um sowas geht? (soll kein Versuch sein, MySQL toll zu reden, ich nutz es momentan, bin aber natürlich immen an Neuem interessiert)
gepostet vor 18 Jahre, 9 Monate von schokofreak
Original von Feagor
Original von schokofreak
Wann wird MySQL endlich zur Datenbank???
Was ist stattdessen die beste möglichst kostenlos einsetzbare Datenbank der Wahl, wenns um sowas geht? (soll kein Versuch sein, MySQL toll zu reden, ich nutz es momentan, bin aber natürlich immen an Neuem interessiert)
PostgreSQL.