nicht angemeldet
Hallo !
Lohn es da überhaupt noch PHP zu nehmen, und nicht mspx oder aspx, oder
.Net und aspx kenn ich zwar nicht sehr gut, dafuer kenne aber die ( ASP || (serverseitiges) JavaScript || COM ) - Teilmenge ein wenig.
Das ganze Konzept komponentenbasierter, sprachunabhaengiger Webarchitektur ist imo "reinem" PHP deutlich ueberlegen - das ist aber auch keine Wunder, da man eigentlich Aepfel und Birnen vergleicht, aber dazu spaeter mehr.
Unter ASP ( und somit erst recht unter ASPX ) kann ich Komponenten die in irgendeiner beliebigen Sprache geschrieben sind der Funktionalitaet der Webseite hinzufuegen .
Zwar ist Javascript genausowenig wie PHP alles andere als typsicher - aber wenn der Hauptteil der Anwendungsloigk in den COMponenten liegt hat man hier mit IDL-Typen zu tun und innerhalb der Komponenten mit eienr Typisierung die so streng sein kann wie es die Sprache ( z.B. C++ ) halt zulaesst.
PHP ist , nach dem was ich ueber die Sprache gelesen habe, speziell fuer das Web geschrieben worden. Es wundert mich deshalb immer ein wenig, das PHP solch eine "fette" Datenbank-Schnittstelle hat. Sicherlich ist auch ein Webserver ein Applikations-"Container", aber DESHALB die Anwendungslogik dort auch gleich vollstaendig mitunterzubringen ist imo keineswegs konzeptinell angemessen.
Man kann natuerlich nach bewaehrtem Muster die Anwendungslogik weitgehend an Stored Procedures und Trigger delegieren. Gibt nur zwei Dinge dabei zu berucksichtigen
- Die Objektklammer liegt dann trotzdem erst in der GUI-Schicht
- Nicht jede Datenbank unterstuetzt SP's - MySQL z.B. erst ab den recht neuen 5er Versionen
Um die Flexibilitaet vo ASP-Architekturen, also insbesondere echte 3-Layer zu realisieren, wird man nicht umhinkommen, Teile der Anwendung an externe Komponenten zu delegieren. SOAP und XMLRPC kommen hier imo erheblich in Betracht.
Wenn man das macht, kann man mit PHP wahrscheinlich fast das gleiche erzielen, was man mit ASP hinbekommt.
Allerdings vermisse nach wie vor ein Application_OnStart wie bei ASp in der global.asa
Gruss
Holger
P.S.: Es gibt unter ASP die Maxime dass man Komponenten "nach Moeglickeit" im IIS laufen lassen sollte und nicht in einem externen Prozess. Nach meiner Erfahrung beruht das auf einem Denkfehler. COM-Prozesse werden von OLE immer dann gestartet wenn eine Classfactory instanziiert werden muss. Wenn das ein einfacher "Out-of-process" Server ist, hat man sicherlich den gleichen Overhead wie bei CGI.
Lokale COM Services hingegen, die also unabhaengig von einem Request laufen , haben diesen Overhaed nicht. Und da sowohl "in-process" ( also hier "in-IIS") als auch lokal "inter-process" zwischen lokalen =>M<=TAs ( ! wichtig ) nach meiner Kenntnis mittels shared memory kommuniziert wird, seh ich den Overhead nicht.
Konnte ich auch bei Messungen nie feststellen.