RadPHP vs. Prism Asp.Net

[stahli]

Hallo zusammen,

ich habe gerade mal kurz in diese RadPHP-Videos reingesehen.

Ich habe noch nicht mit PHP gearbeitet, aber das sieht so sehr interessant aus.

Welche grundsätzlichen Gründe gäbe es, sich für Webanwendungen noch für Asp.Net unter Prism zu entscheiden? Ich fand das bei meinem einzigen Test recht aufwändig.

RadPHP scheint mir (auf den ersten Blick) komfortabler und das erstellte Projekt eben auch noch plattformunabhängig zu sein.

[wicht]

Meiner Meinung nach ist PHP eine Katastrophe. Kann sein, dass das RAD-PHP das etwas übersichtlicher gestaltet, ich kenne es nicht..
Natürlich hat man mit PHP den Vorteil der Plattformunabhängigkeit, den das ASP nicht so einfach bietet (Mono kann das glaube ich aber auch, aber dafür bräuchte man dann wohl einen eigenen Server), und dass man das, was man damit gebaut hat, vermutlich bei jedem kleinen Hoster betreiben kann. So ein Windows-Server oder Hoster ist da wohl etwas teurer.

Also ich würde bei den beiden Möglichkeiten PHP vorziehen, ist in meinen Augen aber so etwa wie die Wahl zwischen Pest und Cholera :-D

Hoffentlich bekomme ich jetzt keine Schläge.

Ein schönes Wochenende :stupid:

[Phoenix]

Ich habe lange mit PHP gearbeitet und seitdem ich das erste mal mit ASP.NET in Berührung gekommen bin will ich nicht mehr mit PHP arbeiten. Dafür gibts mehrere Gründe:

1.) Debugger: PHP zu debuggen ist nahezu ein Ding der Unmöglichkeit (wobei ich mir habe sagen lassen, dass der Debugger im RadPHP tatsächlich der erste ist, der einigermassen taugt).
2.) Vorhandene Libraries: Das .NET Framework ist mächtig. Für alles, was man in PHP in mühevoller Kleinarbeit selber schreiben muss, gibt es allein im .NET Framework schon fertige Klassen. Klassische Aufgaben sind hier z.B. Tracing und Logging, die man mit einem sauberen Einzeiler hinbekommt.
3.) 3rd Party support: Du bekommst keine RadPHP Komponenten. Für ASP.NET gibt es u.A. Telerik, DevExpress, Infragistics, die man verwenden kann. Versuch mal, ein gutes AJAX-Fähiges Treeview-Control in PHP zu schreiben.
4.) Performance: PHP ist immernoch interpretiert, .NET ist ein fertiges Kompilat das ausgeführt wird. Zum anderen kann der .NET Jitter das noch auf die Platform optimieren.
5.) Plattformunabhängig: Linux, Apache, mod_mono, PostgreSQL ist ein sehr guter alternativer Stack zum klassischen LAMP :) Oder andersrum: PHP auf Windows ist ekelhaft (die meisten Libraries zur Bildgenerierung gehen z.B. nicht). ASP.NET auf Linux ist im Gegenzug ne ganz saubere Geschichte. Imho ist ASP.NET Plattformunabhängiger als PHP.

[wicht]

Hmm, okay.
Wenn es Linux-Hoster gibt, die über Mono das ASP halbwegs komfortabel unterstützen, würde ich dann wohl auch ASP vorziehen. Weil ich eigentlich nur noch auf Python setze, bin ich da nicht mehr so ganz up-to-date... Was an PHP auf jedenfall ganz schrecklich ist, ist dieses Durcheinander... Manche Funktionen heißen MachEtwas, andere dann Mach_etwas, und dann gibt es vielleicht noch mach_etwas... während man ASP wohl Locker hinschreibt, dank Auto-Complete und so, muss man bei PHP eigentlich immer die Doku aufhaben...

[Neumann]

Hallo,

Python ist auf jeden Fall besser als PHP. Man kann es lesen ohne lange herumzuraten was wohl passiert, es ist komplett objektorientiert und es gibt brauchbare Webframeworks. Es gibt übrigens auch Phyton für das NET-Framework als Sprache (IronPython), kann man in Visual Studio benutzen. Es sollten sich auch ASP-NET Anwendungen damit machen lassen.

Gruß

Ralf

[Phoenix]

Prinzipiell ja. Nur sind die ganzen Mitarbeiter bei Microsoft die an IronPython gearbeitet haben wieder gegangen. Dort tut sich in letzter Zeit nicht mehr viel. Ich würde also nicht unbedingt strategisch auf IronPython setzen wollen wenn ich was kommerzielles machen wollte.

[Hisoka]

Zitat:

Zitat von Phoenix (Beitrag 1055948)

4.) Performance: PHP ist immernoch interpretiert, .NET ist ein fertiges Kompilat das ausgeführt wird. Zum anderen kann der .NET Jitter das noch auf die Platform optimieren.

Das stimmt mal gar nicht. PHP wird zwar standardmäßig interpretiert, aber man kann auch genauso einen PHP Compiler nutzen und seine Anwendung in Binärcode übersetzen.(z.B. Roadsend PHP Compiler)

Zitat:

Zitat von Phoenix (Beitrag 1055948)

5.) Plattformunabhängig: Linux, Apache, mod_mono, PostgreSQL ist ein sehr guter alternativer Stack zum klassischen LAMP :) Oder andersrum: PHP auf Windows ist ekelhaft (die meisten Libraries zur Bildgenerierung gehen z.B. nicht). ASP.NET auf Linux ist im Gegenzug ne ganz saubere Geschichte. Imho ist ASP.NET Plattformunabhängiger als PHP.

Naja bei mono darf man immer beachten das es von der Performance diverse Macken hat und dazu war der GC bis jetzt nicht gerade der Weißheits letzter Schluss. Auch würde ich gerne wissen wo ASP.NET plattformunabhängiger sein soll. Ich kann mit Gewissheit sagen das PHP auf weit mehr Plattformen läuft als ASP.NET je erreichen wird. Neben dem das .NET Code nicht von hause aus wirklich portabel ist. Viele Anwendungen die ich bisher gesehen hab mussten für Mono extra angepasst werden.

Auch gibt es seit einiger Zeit sehr viele und mächtige Webframeworks für PHP. Gerade das Zend Framework ist nicht zu unterschätzen.

[Phoenix]

Zitat:

Zitat von Hisoka (Beitrag 1056102)

Naja bei mono darf man immer beachten das es von der Performance diverse Macken hat und dazu war der GC bis jetzt nicht gerade der Weißheits letzter Schluss. Auch würde ich gerne wissen wo ASP.NET plattformunabhängiger sein soll. Ich kann mit Gewissheit sagen das PHP auf weit mehr Plattformen läuft als ASP.NET je erreichen wird. Neben dem das .NET Code nicht von hause aus wirklich portabel ist. Viele Anwendungen die ich bisher gesehen hab mussten für Mono extra angepasst werden.

Also seit Mono 2.6 ist der GC besser als der von .NET und die Performance ist schon seit Mono 2.4 mit der von Microsofts .NET mindestens ebenbürtig.

Und Mono läuft im Prinzip überall. Ich würde gerne wissen auf welchen Plattformen PHP Deiner Meinung nach angeblich läuft, auf denen Mono ebenso angeblich nicht laufen soll. Ich habe bisher keine einzige ASP.NET Anwendung gesehen, die nicht ohne Anpassungen auf Mono lief. Selbst solche, die z.B. die Komponenten von Telerik benutzen und ziemlich komplexe Sachen machen.

Was Desktop- und Konsolenanwendungen angeht mag das anders aussehen, aber die sind hier zum einen out of scope, und zum anderen gibt es da immer klassische Ursachen für. Wer z.B. nicht immer Environment.NewLine nimmt und Backslashes in Pfade hartcodiert ist selber schuld. So jemand schreibt auch in den Programm-Ordner und frisst kleine Kinder. ;-)

[Jens Hartmann]

Hallo zusammen,

ich würde gerne dieses Thema nochmal aufgreifen. Ich habe mir das kürzlich mögliche Angebot Upgrade Delphi XE2 auf RAD Studio XE2 gekauft.
Folgende Gründe haben mich zu dieser Entscheidung gebracht:

- Möglichkeit PhP und Prism

Ich würde mich gerne in diese Programmierungen einarbeiten (Interesse und siehe unten).

Allerdings bin ich mir aktuell noch nicht ganz sicher, was das richtige Produkt ist. Mein Ziel ist es, eine vorhanden Windowsanwendung mit einem Zusätzlichen WebClient zu versehen.

Soll heißen, ich möchte meine Server/Client Anwendung basierent auf den Server/Client Socket Komponeten um ein nützliches Webtool erweitern. Leider kenn ich aktuell weder Prism noch RADPhP und zum Thema Tutorial oder Dokumentation bin ich bislang auch nicht erfolgreich auf die Suche gegangen. Ich weiß es gibt die RADPhp Doku und die Oxygene Homepage. Allerdings als Anfänger sehr umfangreich. Daher würde mich interessieren:

- Gibt es gute Tutorials für Einsteiger?
- Gibt es gute Bücher?
- Und welche der beiden Sprachen wäre hier am nützlichsten?

Vorab vielen Dank und Gruß Jens

[mkinzler]

So direkt eignet sich da keines der beiden Produkte:
-Beides sind Erweiterungen eines Webservers
-PHP ist eine komplett andere Sprache, Oxygene basiert zwar auf Pascal ist aber nur bedingt zu Delphi kompatibel ( lehnt sich eher an c# an)
-Die Bedienung einer Webanwendung unterscheidet sich von der einer Windowsanwendung

Man könnte höchstens eine Brücke zwischen der Anwendung und dem Webinterface schaffen (2 getrennte Anwendungen)