AMFPHP > genereller Aufbau einer Webapplikation
Hallo,
ich bin ein clientseitiger Flash Progger, d.h. von PHP spezifischen sachen verstehe ich nicht allzuviel , die basics halt, aber meine Frage geht auch eher in den Bereich Architektur. Wir, ich und ein PHP progger sollen eine Web applikation basteln, die AMFPHP benutzt, nun eine generelle Frage. Findet Ihr daß man in PHp versuchen sollte Design Pattern für die Applikation zu verwenden, solche Pattern wie BusinessDelegate oder ServiceFacade, wie man sie aus J2EE kennt ? um eine Applikation stabil und skalierbar zu bauen ? Oder 'reicht' es einfach scripte abzuarbeiten, aber ich denke da verfehlt man AMFPHP ein wenig ? Mein Kollege lässt sich schwer umstimmen und vielleicht habe ich ja Unrecht...
Da ich wie gesagt aus dem clientseitigen Bereich komme sind mir Server eh nicht so vertraut. Wie würdet Ihr eine Applikation strukturieren in PHP (MVC ? oder )
Noch ein Kommentar > Mir geht es NICHT darum hier eine Lösung abzugreifen, ich kann das schon selbst <grins>
Will nur mal von ein paar erfahrenen PHP proggern hören was so ganz generell die Desiogn Strategien sind, und ich kenne halt die J2EE Design Pattern, vielleicht nimmt man in PHP was ganz anderes ?
Bin gespannt auf Feedback.
Gruss Amir
Antworten
2.
hi ,nein nicht wirklich ... ist glaub ich auch schwer die frage zu formulieren ...
also das ist so, der jung mit dem ich das mach der kommt tatsächlich eben aus der prozeduralen Programmierung.
Und schreibt seine Skripte auch so. verpackt alle in einzelne Funktionen. Ich versuche in Umzustimmen und zu sagen, hey nim OOP , > Singleton, MVC, Dispatcher, Composite.... okay, aber er sagt es sei performanter alle in Funktionen zu packen.
Jetzt bin ich halt ein wenig verunsichert und will auch nicht rumstressen , aber ich denke dass ein script mit 25 riesen funktionen auf das 200 - 300 User zur 'selben' zeit zugreifen,, kann doch nicht klappen oder ?
Daher würde ich gerne wissen ob ich unrecht habe ...
3.
Also ich schreibe alle Scripte mit OOP und das ist allgemein auch so üblich in PHP. Wüsste nicht was man da anders machen sollte ausser eben auf OOP zu verzichten.Ich glaube Du kannst PHP nicht wirklich mit JAVA vergleichen... zumal PHP wesentlich schneller ist ;-)))
4.
okay, das hilft, dankeNoch ein schönes WE
ich ziehe hiermit offiziell meine etwas 'dä(h)mliche' Frage zurück <grins>
Vielen Dank nochmal
5.
Die Frage war nicht dämlich.6.
also allgemein üblich ist es nicht unbedingt mit php oop zu entwickeln (leider). Habe mitterlweile genug größere projekte kennengelernt die prozedural geschrieben worden sind. Und kennengelernt habe ich diese Projekte nur, weil sie alle mist waren bez. erweiterbarkeit und modularität.Kommt ganz darauf an was man haben will.
Meine Meinung ist, das wenn auch nur die geringste Möglichkeit besteht, das mal änderung an den skripten vorgenommen werden sollen, ist oop vorzuziehen.
Performanter sind prozedurale phpskripte nicht wirklich. Sie sind wohl nicht ganz so speicherintensiv, da weniger overhead.
Aber der Unterschied ist so marginal.
Und DesignPatterns sollte man dann wohl auch verwenden wenn möglich. Wo wäre denn sonst ihre daseinsberechtigung ;)
7.
Also ich habs mir mittlerweile angewöhnt jeden kleinen scheiss mit oop zu programmieren... seitdem hab ich auch keine Probleme mehr mit Übersichtlichkeit und umherschwirrenden Variablen.Gerade bei nem CMS ist das grösste Problem, dass man ohne OOP irgendwann eine Variablenvielfalt im Maincode hat, die meiner Meinung nach gar nicht mehr zu überblicken ist... darum: Was nur geht in Klassen auslagern. So schafft man prinzipiell auch schon eine gewisse modularität.
8.
nun ja... prozedurale phpskripte sind wirklich deutlich schneller in der ausführung als oo skripte, wegen speicherbedarf und ähnlichem. aber wenn das das einzige argument ist für prozedurale programmierung, dann guck dir mal an, wie php-skripte die in spagetti-code geschrieben sind abgehen *g*das einzige argument, was gegen oo spricht ist, dass man mehr zeit in die planung stecken muß. das macht sich aber in der wartung und bei der erweiterbarkeit der software bezahlt. vor allem bei größeren projekten ist oo eigentlich ein muß. allerdings unterstützen im moment noch nicht besonders viele server php5, wodurch die möglichkeiten eigentlich auf php4 beschränkt werden müssten. und da war leider noch nicht so ganz viel mit möglich.