Art von OO in PHP / Programmierstil bei großen CMS / Frameworks

[Dario Linsky]

Tja... was mir an ASP missfällt? da fängs schon beim syntax an... ich kann erstmal diesen VB syntax schon nich leiden und dann auch noch tsags wie <% nein is nicht meine sache...

Wieso VB? Bei ASP.NET kann man auch ohne VB was erreichen, XSP kann sogar glaube ich nur C#. Ich würde mich auch hüten, nochmal einen Finger an VB zu legen, solange ich Linux benutze.
Was ist an dem Tag so schlimm? JSP-Seiten benutzen das doch auch, das ist keine ASP-Domäne.

 

[chibisuke]

Naja dann brauch ich aber kein ASP mehr wenn es eh in C# geschrieben wird, weil dann jag ich den code durch n kompiler link ne CGI oder SAPI lib dazu und bind es entsprechend an die site an...

natürlich kann man ASP in mehreren sprachen programmieren, meines wissens gibts sogar n PHP interface zu ASP (ActivePHP)... naja ansonsten is mit VB und JS bekannt das man mit arbeiten kann, nur irgendwie.. ja... naja eigendlich sollte es genügen wenn ich sage das ich es net leiden kann und dafür diverse gründe habe...

 

[Christian Fein]

Original geschrieben von chibisuke
Naja dann brauch ich aber kein ASP mehr wenn es eh in C# geschrieben wird, weil dann jag ich den code durch n kompiler link ne CGI oder SAPI lib dazu und bind es entsprechend an die site an...

Extrem ineffizient. Gerade J2EE und auch .NET sind in der Lage threaded über Servlets / Pages zu laufen, und du willst für jeden Request einen Thread aufmachen.
Sorry aber informier dich bitte erstmal über die Techniken, bevor du sie verteufelst. Denn grade um ineffiektivität zu vermeiden die bei CGI und SAPI entstehen sind solche Techniken erfunden worden.

 

[chibisuke]

Extrem ineffizient. Gerade J2EE und auch .NET sind in der Lage threaded über Servlets / Pages zu laufen, und du willst für jeden Request einen Thread aufmachen.
Sorry aber informier dich bitte erstmal über die Techniken, bevor du sie verteufelst. Denn grade um ineffiektivität zu vermeiden die bei CGI und SAPI entstehen sind solche Techniken erfunden worden.

jein... nur wenn es als CGI leuft, denn dann wird jedesmal ein eigener prozess erstellt... bei SAPI sieht die sache ein wenig anders aus...
fals es dir noch net aufgefallen sein sollte, ob nun ASP oder JAVA oder ein eigenes progy einen thread aufmacht um die arbeiten auszuführen, das kommt geschwindigkeitsmäßig aufs gleiche raus... auch was die resourcenverwendung betrifft... thread is nunmal thread und das wird sich auch durch ASP und ähnliches nicht ändern...

wie man wenn man genauer hinguckt sieht, erstellt nahezu jedes SAPI modul einen eigenen thread für einen seitenaufruf.. (alternativ könnte man die threads wiederverwenden, is aber totaler blödsinn da die n haufen resourcen verbrauchen dadurch)... und bei CGI is es net viel anders nur mit dem unterschied das hier das ganze in einem eigenen prozess leuft und für jeden seitenaufruf n eigener prozess leuft...

um dieses verhalten kommt auch java oder asp net rum, es is so und wird sich net ändern, weil das zaubern wurde bis heute nicht erfunden...


so und nun sag mir wo der vorteil liegt wenn ich eine interpreter sprache habe die nen eigenen thread für einen seitenaufruf erstellt, gegenüber einem fertig kompilierten modul welches die selbe arbeit auf die gleiche weise erledigt..... da bleibt nur die leichtere änderbarkeit eines scripts als vorteil übrig...

Ich bin über die funktionsweise genauestens informiert, und ich weiß wovon ich rede, ich hab in meinem leben schon ettliche CGIs sowohl kompiliert als auch interpretiert geschrieben, und auch SAPI module hab ich noch einige experimente hinter mir...

das einzige was du mir vorwerfen kannst wo ich (noch) zu wenig informiert bin das ist fastcgi...

naja egal... das wird jetzt hier zum also...

 

[Christian Fein]

jein... nur wenn es als CGI leuft, denn dann wird jedesmal ein eigener prozess erstellt... bei SAPI sieht die sache ein wenig anders aus...
fals es dir noch net aufgefallen sein sollte, ob nun ASP oder JAVA oder ein eigenes progy einen thread aufmacht um die arbeiten auszuführen, das kommt geschwindigkeitsmäßig aufs gleiche raus... auch was die resourcenverwendung betrifft... thread is nunmal thread und das wird sich auch durch ASP und ähnliches nicht ändern...

Da besteht ein Riesen unterschied, denn CGI starten Childprozessen was um massen langsamer ist als Threaded drüber zu laufen.
Nachteil zudem von SAPI ist das ein Fehler in der Applikation den ganzen Webserver abstürzen lassen kann da sie innerhalb des Hauptprozesses des Webservers laufen.
Zudem sind SAPI erweiterung alles andere als portable.

wie man wenn man genauer hinguckt sieht, erstellt nahezu jedes SAPI modul einen eigenen thread für einen seitenaufruf.. (alternativ könnte man die threads wiederverwenden, is aber totaler blödsinn da die n haufen resourcen verbrauchen dadurch)... und bei CGI is es net viel anders nur mit dem unterschied das hier das ganze in einem eigenen prozess leuft und für jeden seitenaufruf n eigener prozess leuft...

um dieses verhalten kommt auch java oder asp net rum, es is so und wird sich net ändern, weil das zaubern wurde bis heute nicht erfunden..

JSP/J2EE arbeitet mit Servlet Instanzen die im Speicher gehalten werden und da threaded drüber gelaufen wird. Ähnlich SAPI nur mit dem Unterschied das es Zuverlässiger, Sicherer und Portabler ist.
CGI ist eine veraltete Technik, da Childprozesse für jeden Besucher erstellt werden.

so und nun sag mir wo der vorteil liegt wenn ich eine interpreter sprache habe die nen eigenen thread für einen seitenaufruf erstellt, gegenüber einem fertig kompilierten modul welches die selbe arbeit auf die gleiche weise erledigt..... da bleibt nur die leichtere änderbarkeit eines scripts als vorteil übrig...

PHP = Interpretert
Java = JIT Compiliert
.NET = JIT Compiliert

Gerade in Webanwendungen verfliesst der Geschwindigkeitsnachteil von Gejitteten Sprachen, da Servlets permanent angesteuert werden und somit schon in kompilierter Form vorliegen.
Die anderen Vorteile habe ich dir schon genannt.

Ich bin über die funktionsweise genauestens informiert, und ich weiß wovon ich rede, ich hab in meinem leben schon ettliche CGIs sowohl kompiliert als auch interpretiert geschrieben, und auch SAPI module hab ich noch einige experimente hinter mir...

Ist ja schön für dich. Aber von J2EE und ASP.net hast du keine Ahnung. Das zeigt sich dadurch das deine Aussagen diese Techniken betreffend einfach alle falsch sind.
Les dich bitte erstmal in J2EE ein, bevor du darüber urteilst.
Ich urteile auch über PHP, nach mehreren Jahren die ich damit beruflich und privat arbeite.

das einzige was du mir vorwerfen kannst wo ich (noch) zu wenig informiert bin das ist fastcgi...

fastcgi ist ein guter Ansatz. Aber noch nicht ausgereift. Sobald Anfragen konkurieren wird auch weiterhin ein neuer Prozess gestartet.

 

[chibisuke]

Man könnte die diskusion hier sicher bis ins unendliche ziehen... doch fakt ist, das sowohl die Servlet interpreter als auch ASP interpreter wie es auch PHP oder in neueren versionen von Perl geschieht, als SAPI module laufen, und das wird sich nicht ändern...

nun sehe ich insofern keinen vorteil in der performance wenn ich ein solches script laufen lass gegenüber einem SAPI das ich selbst geschrieben hab.

bleibt nur die absturzsicherheit, und wenn man ordendlich programmiert, und vor allem ab und zu auch mal n SEH benutzt stellt sich auch dieses problem nicht.

Lassen wirs, das is etwas worüber man vermutlich ne 1000 seitige abhandlung verfassen könnte und immer noch nicht alle aspekte betrachtet hatt...

und was fastcgi betrifft,,, soweit ich weiß leuft das PHP-fastcgi in einem einzigen prozess der mithilfe von von TSRM dann einzelne threads erstellt...naja aber den source von der fastcgi lib von PHP hab ich noch nich ganz durchgearbeitet, dazu hatt ich noch keine zeit...

außerdem glaub ich im handbuch von PHP gelesen zu haben das auch PHP just in time kompiliert wird...aber ganz sicher bin ich mir da net..

 

[Transmitter]

Ist TSRM dann ein eigenständiger Prozess auf der Maschine oder läuft der Intern in PHP oder Apache?


Um nochmal zurück zu kommen auf das Ursprüngliche Thema:

Christian´s kurze OO Einführung war ganz nett für die Grundlagen, nur leider weniger Portierbar auf relevante Umgebungen innerhalb von Modulen.

Wie würdet ihr denn ganz konkret ein Newsmodul realisieren?

Wieviele Klassen, Attribute, Methoden, welche Vererbungsstruktur, und welche Klasse ist für was zuständig?

Auf welche Klassen greifen die Klassen aus dem Modul zu, und was genau habt ihr generalisiert?

 

[chibisuke]

TSRM kompiliert zur lib... ausgeschrieben heißt es ThreadSave Resource Manager soweit ich weiß, und bewirken tut es im prinzip das selbe wie in windows der TLS (Thread Local Storage)

also das heißt im pinzip das du abhängig davon welchen thread du benutzt du unter dem selben variablennamen verschiedene werte vorfindest so auf die art is das... je nachdem welche implementation benutzt wird...

das braucht man in PHP wenn man mehrere php scripts gleichzeitig im selben prozess ausführen will, sonst überschneiden sich die und im schlimsten fall kommts sogar zur access violation

Nun ein news modul würde ich vermutlich in 3 teile aufspalten...
Datenbank zugriff, funktionalität, anzeige

entsprechend mit einer datenbank klasse für den zugang zur datenbank, eine news klasse die die funktionen wie readNews, addNews ect. ect. zur verfügung stellt und eine klasse oder auch als sites, je nachdem wie man es realisiert hatt... für die anzeige des ganzen in der website

 

[Christian Fein]

Original geschrieben von chibisuke
Man könnte die diskusion hier sicher bis ins unendliche ziehen... doch fakt ist, das sowohl die Servlet interpreter als auch ASP interpreter wie es auch PHP oder in neueren versionen von Perl geschieht, als SAPI module laufen, und das wird sich nicht ändern...

So langsam bin ichs leid das du nicht zuhörst. Ich schreibe dir jetzt zum letzen mal das
ASP.net und Java gejittet wird.
JIT = Just in Time Compiliert.
Zudem ist die Virtuelle Mashine kein Interpreter da bei Java und auch .NET kein Programm Code interpretiert wird, sondern bytecode bzw msil ausgefuehrt wird.
Java erreicht 90 % der Geschwindigkeit von C++ und ist um Massen schneller als PHP.

So und nu hör endlich auf von Interpretierten Sprachen zu reden, und nimm dir erstmal ein Buch in die Hand und les das da nach, sonst hat die ganze Diskussion kein Wert.

 

[chibisuke]

ja das weiß ich...
nur is es in dem fall ziemlich irrelevant...
und damit is jetzt schluss, ich bin die diskusion langsam leid, wenn du meinst Java benutzen zu müssen bitte, wenn du meinst dir dafür n eigenen server hohlen zu müssen weil es kaum anbieter gibt die dir das bieten.. nicht mein bier..
ich für meinen teil bleib entweder bei PHP oder wenns schon was anderes sein muss, dann C++ und wenn ich ganz lustig drauf bin mit unter auch mal assembler..
jedem das seine, und es bringt nix zu streiten was das bessere is oder nich, weil alles hatt seine vor und nachteile und manche dinge sind dann einfach nur noch unintessant... so wie diese diskusion, aus schluss punkt .