Delphi oder PHP?

**alcaeus**

Hallo davar,

ich musste mal eine ähnliche Anwendung (Webinterface für ein Kommissionierungsmodul) programmieren, und mein Chef hat mir IntraBase aufgezwungen (ist sowas wie ASP.NET), und ich muss sagen: vergiss den Teil.
Ich würde sowas definitiv in PHP machen, wobei man dort einiges an Funktionalität liegen lassen muss.
ALlerdings gibt es mit ASP .NET und Webforms eine schöne Alternative, die auch sehr gut funktioniert (jedenfalls hat es bei Daniel Magins Vortrag so ausgesehn

), und die Entwicklung war auch nicht sehr aufwändig. Informier dich mal darüber, vielleicht ist es das was du brauchst

Greetz
alcaeus

**Phoenix**

Zitat von MrSpock:

ist es denn nicht so, dass man sich mit .NET im wesentlichen auf den Microsoft Internet Information Server beschränkt und das Ganze auf den weit verbreiteten Apache Server dann nicht lauffähig wäre? Deshalb könnte PHP vielleicht flexibler eingesetz werden!? Oder lieg ich da jetzt total falsch

?

Da liegst Du total falsch

dotGNU unterstützt ASP.NET und ADO.NET (Version 1.1) inzwischen komplett. Es ist also kein Problem dein Assembly einfach auf einen Apache mit dotGNU zu kopieren und Dich an der Performance zu freuen, die sogar ein Stückchen über der des IIS liegt

**franktron**

Bevor das in was für ein Sprache geht alles Dikossion ausartet mal die frage wo sthet den überhaupt der Server wo die DB drauf ist soll der zugriff nur im Intranet statfinden ist es euer Server (root zugriff) was für ein OS hat der Server überhaupt welcher Webser läuft drauf Apache IIS oder was anderes.

**Phoenix**

Zitat von alcaeus:

ALlerdings gibt es mit ASP .NET und Webforms eine schöne Alternative,

... die allerdings im Bereich UserInterface tatsächlich etwas hinterherhinkt.

Nun aber das grosse ABER: Drag&Drop ist schön und gut, aber nehmen wir einmal das Beispiel Buchhaltungssoftware. Die Kunden würden Dir eine Software um die Ohren hauen, die Du mit Drag&Drop bedienen musst um z.B. Kontozuordnungen zu machen.

Die meisten Anwender (natürlich nicht alle, aber dennoch ein grosser Teil) ist darauf bedacht ihre Pfoten so wenig wie möglich von der Tastatur zu nehmen. Manche die mal Shortcuts ausprobiert haben brauchen die Maus gar nicht mehr weil sie ohne einfach schneller sind.

Will heissen: Ein Gutes UI muss mit Tastatur, Tabs und Shortcuts zu bedienen sein, und das geht alles mit (X)HTML. Sogar links lassen sich mit Tastaturshortcuts bedienen, auch wenn man die ASP.NET Controls hierfür noch ein wenig selber anpassen muss.

Aber um nochmal zu meinem Argument zurückzukommen: Die richtige Wahl ist in diesem Fall auf jeden Fall ein Webservice. Man kann dazu ein UI in ASP.NET WebForms basteln, die den Webservice nutzen, man kann aber auch in ein paar Minuten ein WinForm basteln, das die Daten hintenrum an den Webservice schickt und die Daten nur anzeigt.

Ergo: Einmal logik implementiert (am besten in Delphi.NET), einmal ein webbasierte Oberfläche Implementiert (am besten in Delphi.NET oder C#) und einmal eine Echse gemacht, die nur Formulare beinhaltet die mit dem Server kommunizieren (für die handliche Bedienung) - auch in .NET.

Man kommt wunderprächtig ohne PHP aus (es hat sich gezeigt das viele kommerzielle komplexe PHP-Anwendungen einfach zu teuer in der Wartung sind), man muss den Quellcode nicht dem Kunden mit ausliefern (was bei einer interpretierten Scriptsprache ja Zwangsläufig so ist) und man ist dennoch Platformunabhängig und Zukunftsorientiert. Und zudem noch ungeheuer Flexibel.

**Phoenix**

Zitat von franktron:

Bevor das in was für ein Sprache geht alles Dikossion ausartet mal die frage wo sthet den überhaupt der Server wo die DB drauf ist soll der zugriff nur im Intranet statfinden ist es euer Server (root zugriff) was für ein OS hat der Server überhaupt welcher Webser läuft drauf Apache IIS oder was anderes.

Ist doch vollkommen egal. Sowohl PHP als auch Delphi (.NET) - Anwendungen laufen sowohl mit Apache als auch mit dem IIS. Nur mit Websnap hätte man auf Linux wohl etwas Probleme

Und der Server auf dem die DB ist sollte idealerweise sowieso eine andere Kiste sein als die, die den Webserver beherbergt. Allein aus Sicherheitsgründen.

**franktron**

Zitat von Phoenix:

Zitat von franktron:

Bevor das in was für ein Sprache geht alles Dikossion ausartet mal die frage wo sthet den überhaupt der Server wo die DB drauf ist soll der zugriff nur im Intranet statfinden ist es euer Server (root zugriff) was für ein OS hat der Server überhaupt welcher Webser läuft drauf Apache IIS oder was anderes.

Ist doch vollkommen egal. Sowohl PHP als auch Delphi (.NET) - Anwendungen laufen sowohl mit Apache als auch mit dem IIS. Nur mit Websnap hätte man auf Linux wohl etwas Probleme

Und der Server auf dem die DB ist sollte idealerweise sowieso eine andere Kiste sein als die, die den Webserver beherbergt. Allein aus Sicherheitsgründen.

Das eben nicht egal wenn man nämlich keinen zugriff auf den Server hat kann man auch keine .NET installieren

**Phoenix**

Zitat von franktron:

Das eben nicht egal wenn man nämlich keinen zugriff auf den Server hat kann man auch keine .NET installieren

Ist es ein eigener Server: Eh kein Problem. Sollte es ein angemieteter Server sein sagt man das dem Anbieter und wenn der nicht spurt (will heissen Nachinstalliert) wechselt man zu einem anderen. Ist doch recht einfach. Ich lasse mir doch von einer bestehenden Infrastruktur nicht meine Zukunftsperspektiven vorschreiben. Und darum geht es hier ja: Zukunftsorientierung. Da muss ggf. die bestehende Infrastruktur erweitert oder gar ersetzt werden. Sonst würde das ja Gegenwartsorientierung heissen

**MaBuSE**

Zitat von davar:

Mir wurde von einem Vorgesetzten folgender Satz zugeschmissen
"Webbasierte Programme sind zukunftsorientiert, deswegen sollten wir alles webbasiert programmieren."
Mit webbasiert meint er die Verwendung von MySQL mit PHP und dem Zugriff über den Browser, weil man so ohne Installation von Zusatzprogrammen von jedem Rechner aus zugreifen kann.

Wie in diesem Thread schon gesagt wurde: .net ist die Zukunft
Grund sätzlich kann man auch vieles in php programmieren (keine Frage), aber wenn schon das Programm steht und nun eine web fähige Version her muss, gibts noch einen anderen Weg.

Das ist nicht die optimale Lösung, aber es funktioniert.
(zumindest auf Windows Rechnern mit Internet Explorer)

Pack das ganze in ein ActiveX und dann kannst du es aus dem Browser verwenden.

Habe gerade nochmal im Delphi 5 nachgeschaut (D3 habe ich nicht mehr installiert):
Menu "Datei -> Neu... -> ActiveX -> ActiveForm" auswählen -> Dialog erscheint
z.B. "Info Fenster inzufügen" auswählen und OK drücken
-> es wird ein ActiveFormProj1.dpr angelegt (Hauptprogramm -> dll)
-> es wird ein ActiveFormImpl1.pas angelegt (das hinzugefügte Form)
-> es wird ein About1.pas hinzugefügt (das Info Fenster)

Im Info Fenster ist folgende procedure definiert:

markieren

Delphi-Quellcode:

			procedure ShowActiveFormXAbout;

begin

  with TActiveFormXAbout.Create(nil) do

    try

      ShowModal;

    finally

      Free;

    end;

end;

-> also ganz normales Delphi

Ziehe ein TMemo und 2 Buttons auf das Formular
Einen Button mit ShowActiveFormXAbout; belegen den anderen mitclose; nun abspeichern

Das "Programm" kann natürlich nicht so einfach ausgeführt werden (ist ja eine dll)

Also -> Menü "Projekt -> Optionen für Web Distribution...

hier kann der eigene Webserver eingetragen werden (Verzeichnis, URL, ...)

Dann mit Menü "Projekt -> Distribution über das Web" aufrufen und im Internet Explorer ausprobieren

Viel Spaß

ps: Das ist nicht die beste Lösung, aber es ist ein "einfacher" Weg. Ich persönlich würde aber zu .NET mit WebServices tendieren.

**woki**

Hi,

die Antwort ist relativ einfach:

Komplexe, webbasierte Systeme mit Zugriff auf Datenbanken(incl. MySQL) lassen sich z.B. in Delphi effizienter, schneller, kostengüsntiger, performanter, skalierbarer, wartbarer und fehlerfreier entwickeln als in einer Skripsprachen, die serverseitigen Code in HTML-Templates einbetter, die also Layout und Businesslogik verschmelzt.

Eine webbasierte Anwendung in Delphi mit Datenbankanbindung, Daten abholen, darstellen, editieren und rückschreiben in die Datenbank, und Sessionverwaltung, baue ich in weniger als fünf Minuten from scratch, inclusive deployment in den Testserver und Darstellung im Browser.

Um praktisch zu beweisen, was theoretisch klar ist, suche ich immer noch Vertreter der PHP Fraktion, die unter folgenden Konditionen dageben halten:

Du bekommst einen Computer mit

laufender Datenbank
installiertem PHP
Browser
und fünf Minuten Zeit.
Und dnan will ich dasgleiche in PHP sehen.

Je komplexer die Anwendugen werden, desto krasser wird der Unterschied.

Für komplexe Anwendungen, die nicht darauf angewiesen sind, auf einem 3,5 Euro 1&1 Account zu laufen, ist die Frage nicht Delphi oder PHP, sondern Delphi, oder C# oder Java.

Grüsse
Woki

P.S. Ich empfehle deinem Chef, etwas Geld für Beratung auszugeben, bevor er unendlich viel davon in den Ausguss schütet.

**Alfons_G**

Hier wird ja leidenschaftlich diskutiert

Tatsache ist doch einfach, dass ich zuerst wissen muß, was erwartet der Kunde von einer Anwendung. In einem Pflichtenheft muß festgelegt werden, welche Anforderungen essentiell sind, welche wünschenswert und welche "nice to have". Dann kann man auch entscheiden, wie die Anwendung konzipiert werden muß. Die Entscheidung für die Programmiersprache spielt an dieser Stelle noch gar keine Rolle.

Falls ein Programm auf lokale Ressourcen des Anwender-PCs zugreifen muß, muß es zumindest einen lokalen Teil geben, welcher z.B. mit der Peripherie des jeweiligen PCs kommunizieren kann.
Falls hinter dem Programm eine Geschäftslogik steckt, welche unabhängig vom jeweils installierten Versionsstand der Anwenderschnittstelle aktuell sein muß, dann muß zumindest ein Teil der Funktionalität auf dem Server liegen
Falls die Anwendung ohne Installation von jedem Rechner im Intranet aus erreichbar sein muß, muß das Programm vollständig auf dem Server liegen

Absolut portabel ist natürlich eine Webanwendung, welche im Browser ohne externe Plug-Ins läuft. In einem Intranet hat man zumindest den Vorteil, dass man im Allgemeinen eine homogene Browserlandschaft vorfindet. Man kann sich also an den üblicherweise vorhandenem Browser orientieren.
Damit verfügt man über einen "thin client", ohne eigene Intelligenz, nämlich den Browser, der nur Aus- und Eingabe der Daten abwickelt und die Formulare darstellt.
Der Nachteil ist, alle Daten müssen von der Server-Anwendung verifiziert werden. Auch wenn man eine Eingabeüberprüfung mit JavaScript implementiert - man kann sich nie darauf verlassen, dass der User es auch aktiviert hat. Alle Änderungen der Eingabemaske erfordern das Senden der Daten zum Server, welcher daraufhin die neue Maske zurückgibt. Das erhöht den Datenverkehr und die Serverlast. Berichte müssen auf dem Server in HTML oder Pdf erstellt werden, um ggf. aus dem Browser heraus gedruckt zu werden.

Die Alternative ist ein "fat client". mit dem man bei der in Delphi ab Enterprise unterstützten Three-Tier-Anwendung ankommt. Man hat also eine lokale Anwendung, welche interaktive Veränderungen an der Benutzeroberfläche erlaubt, Reporting-Funktionen besitzt und die Eingabedaten lokal prüft und in ein für den Server vorhersehbares Format bringt.
Der Server wiederum dient als Applikationsserver. Er bearbeitet die Daten gemäß den aktuellen Geschäftsregeln und interagiert seinerseits mit der dritten Schicht, dem Datenbankserver. Außerdem steuert er das lokale Programm und liefert die jeweils aktuellen Regeln für die Benutzeroberfläche.

Eine lokale Anwendung ist am einfachsten zu schreiben, da man sie mit einem Werkzeug wie Delphi mit relativ wenig Aufwand zusammensetzen kann. Allerdings muß dann bei jeder Änderung auch sichergestellt werden, dass alle Anwender auch die aktuellste Version installiert bekommen.
Ein fat client muß dagegen nur geupdatet werden, wenn sich die Funktionalität der Oberfläche ändert. Änderungen in der Datenverarbeitung werden nur in der Serveranwendung durchgeführt.
Eine Web-Anwendung kann ich immer aktualisieren, ohne dass der Anwender mit Updates in Berührung kommt.
Anwendungen mit ActiveX, bzw. Java-Applets liegen irgendwo dazwischen. Wenn die Komponenten aktualisiert werden müssen, hat man auch das Update-Problem, allerdings wird es im Browser ausgeführt.

Damit ergeben sich für den jeweiligen Einzelfall Anhaltspunkte, wie man eine Anwendung schreiben soll.

Die Programmiersprache dagegen liegt erst ganz am hinteren Ende der Entscheidungsfindung. Hier sollte man sich nach vorhandenem Know-How, evtl. bereits installierter Server-Hard- und Software usw. richten.

Ich selbst erstelle Webanwendungen mit PHP, VBScript (ASP) und Delphi.
Die PHP-Anwendungen sind mehr interaktive Webseiten. eo die Information im VOrdergrund steht und nicht die Datenbe- und verarbeitung.
Die VBScript-Programme sind für kleinere Benutzerkreise, welche aber oft Anpassungen am Programm beötigen. Das geht hier schnell - Seite in Editor laden, ändern und speichern - fertig.
Mit Delphi dagegen schreiben wir Programme, welche relativ komplex sind und die meistens wieder auf dem Server über ein Fremd-API auf die Software von Drittanbietern zugreifen.

Ein guter Ansatz ist auf jeden Fall der Vorschlag, die Geschäftslogik in einem Web-Service zu implementieren. Dieser läuft als "Applikationsserver light" und kann seine Funktionen sowohl Webanwendungen, Java-Applets, als auch lokalen rogrammen zur Verfügung stellen.
Oft greifen wir zumindest auf diesselben Daten mit Web- und lokalen Anwendungen zu. Für Aufgaben, welche von einigen wenigen Benutzern abgewickelt werden, schreiben wir lokale Programme. Die Aufgaben für größere Anwenderkreise lösen wir dagegen mit Webanwendungen.

Um noch mal auf .NET zu kommen: Damit erhöht man die Produkivität enorm - und mit dem kommenden .NET 2.0 noch mehr. Mann kann auch in PHP sauber programmieren, doch es erfodert mehr Disziplin und Einarbeitung. Und dann sollte man auch eine gute IDE verwenden, wie z.B. Eclipse. Auch bei PHP kann man den QUellcode für den Anwender verschlüsseln - aber das kostet eben ein wenig.
UM eine wirklich gute Produktivität bei PHP zu erreichen, muß man auch in kommerzielle Produkte investieren, ist dafür aber bei entsprechender Vorgehensweise weitgehend plattformunabhängig.
Wenn klar ist, dass man mit der Windows-DotNET-Plattform auskommen wird, fährt man da vermutlich besser. Und - man kann Teise des Quellcodes sowohl für lokale, als auch Webanwendungen verwenden.