Delphi oder PHP?

[davar]

Hallo Leute,

vielleicht ist diese Frage zu allgemein, aber selbst beantworten kann ich sie irgendwie nicht.
Ich sollte vorher sagen, dass wir sehr viel (ständig) mit Datenbanken (MySQL) arbeiten.

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.

Nun aber meine Meinung:
auch interne Programme (Kundenverwaltung (CRM) und eine sehr umfangreiche Datenbank des Online-Shops) werden mit PHP verwaltet. Ich denke jedoch, dass wir bei diesen zwei Sachen lieber auf Applikationen (z.B. mit Delphi geschrieben) zurückgreifen sollten, weil so einfach mehr Möglichkeiten da sind, auch in Bezug auf Benutzerfreundlichkeit und Funktionsumfang.

Was meint ihr dazu?


MfG

davar

[Phoenix]

Ehrliche Meinung?

.NET (egal mit welcher Sprache).

Die mit .NET erstellten Assemblys lassen sich sowohl in normalen Applikationen (rich Clients / Webforms anwendungen) als auch in Webservices oder echten Webanwendungen (ASP.NET) verwenden.

Somit hast Du sozusagen das Beste von beiden Lösungen vereint. Und man kann sowohl Delphi als auch PHP für .NET Assemblys verwenden. Wobei ich hier tatsächlich eher zu Delphi tendieren würde.

Edit Nachtrag: Noch ein Vorteil: Bereits erstellter Code (z.B. eine CRM-Logik in PHP) lässt sich in ein .NET-Assembly packen und mit Delphi in einer normalen Applikation weiterverwenden.

[davar]

naja, .NET ist für mich fernes Neuland, also damit hatte ich ehrlich gesagt bisher nie was zu tun - ausser, dass mir das ständig beim Windows Update ständig angeboten wird :)

Massgebend ist ja die Antwort auf die Frage, ob man direkt auf dem Server, oder lokal und mit den Daten auf dem Server arbeiten sollte - also, Browser oder eigene Applikation. Quasi, ob das, was mir gesagt wurde so schon richtig ist oder man gut gegenargumentieren könnte.

Wie ist es denn bei den anderen in den Betrieben?



MfG

davar

[meierotto]

Hallo,

also, auch wenn mans nicht gerne zugibt, aber dein Chef hat schon recht. Webbasierte Software ist momentan das, was als Zukunft gesehen wird. Da du mit Delphi 3 arbeitest, kannst du .net wohl erstmal vergessen. PHP bedeutet mehr Handarbeit, wenn man es gut beherrscht, kann man aber ebenso benutzerfreundliche Systeme erstellen wie mit Delphi. Und da ihr MySQL verwendet, würde ich auch wirklich bei dieser Kombination bleiben. Aber als Ziel sollte trotzdem der Umstieg auf .net stehen.

Viel Erfolg :wink:

[davar]

hmmmmm.... Hast recht, man gibt es nicht gerne zu :)

Wie weit muss ich denn jetzt denken, wenn du sagst, dass es zukunftsorientiert ist?

Ich stehe vor dieser Frage, weil ich - und viele andere Kollegen auch - mit den Eingabemasken alles andere als zufrieden bin und ich viele Punkte sehe, die man verbessern könnte, ergonomischer genauso wie effektiver.
Und besonders die Tatsache, dass ca. 10 Leute permanent Daten eingeben und weitere 10 sehr oft mit CRM arbeiten, lässt mich die ganze Situation durchdenken.

Und wenn ich mit Zukunftsorientierung an die nächsten 10 Jahre denken muss, halte ich nicht viel davon, weil die derzeitige Situation schnell verbessert werden sollte, daher auch meine Frage.


MfG

davar

[franktron]

Also was in 10 Jahren so für PC gibt oder auch nicht weis wohl keiner aber Browser wirds da wohl noch geben (Denk ich mal)

Aber obs da noch .NET oder Delphi oder PHP gibt weis wohl keiner also nimm am Besten wo du am besten mit klar kommst.

[davar]

hehe..

Ich komme mit Delphi klar und genau das ist ja das Problem :)

Ich muss ja irgendwie gegenargumentieren, warum ich lieber mit Delphi programmieren würde.

Wenn ich sage, ich komme damit besser klar, kann ich ja gleich einpacken und meinen Platz einem PHP-Programmierer übergeben ;)

[Grendel]

Ich selber durfte, obwohl ich von vornehrein dagegen war, eine ziemlich dicke Anwendung in PHP implementieren. Wobei das PHP nebensächlich ist das Problem ist eher (X)HTML.
Ich habe meinen Cheffes mehrfach gesagt, daß ich mir kaum vorstellen kann, daß die gerne in einer Weboberfläche rumhantieren möchten aber bin auf taube Ohren gestossen.
Als sie dann festgestellt haben, daß z.B. Drag&Drop (etc.) nicht funktioniert (was ich denen vorher gesagt hatte) durfte ich den ganzen Rotz in die Tonne kloppen und in Delphi neu erstellen.
Ich bin der Meinung, daß (X)HTML zu wenig Möglichkeiten bietet eine vernünftige Arbeitsoberfläche für Office-Anwendungen zu erstellen. Klar mit JavaScript kann man sich hier und da behelfen aber nur so lange der Benutzer auch JS aktiviert hat. Spricht, es muss auch ohne gehen.
Wenn X-Forms endlich sauber unterstützt werden (wobei der IE dafür wohl noch 5 Jahre braucht; Er kann ja nichtmal CSS2) sieht das ganze anders aus aber bis dahin halte ich (X)HTML Oberflächen für wenig brauchbar.

Du kannst Deinem Chef ja z.B. mal eines der zahlreichen PHP-CMSe installieren. Ich denke da wird er ganz schnell feststellen, wie unkomfortabel das ganze ist.

Bis neulich ...

[davar]

@Grendel:

du sprichst mir aus der Seele :-)

Ich brauche ihm noch nicht einmal was zu installieren, wir arbeiten schon mit solchen Oberflächen, es ist unkomfortabel und das sagen alle laut und deutlich. Also, noch taubere Ohren kann ich mir fast gar nicht mehr vorstellen. :)

Daher ja auch meine Frage, ob man durch geschicktere PHP-Programmierung tatsächlich mehr erreichen kann oder doch Delphi mit den GUI-Funktionen einfach besser ist (Drag&Drop, benutzerdefinierte Oberflächen, Menüs, PopUpMenüs etc.).

[Grendel]

Zitat:

Zitat von davar

Daher ja auch meine Frage, ob man durch geschicktere PHP-Programmierung tatsächlich mehr erreichen kann ...

Nein. Das hat wie gesagt auch nix mit PHP zu tun, da PHP zur Darstellung der Oberfläche auch "nur" (X)HTML ausspuckt. Durch JavaScript kann man hier und da noch einige "Komfortmerkmale" (ich denke es ist klar was ich damit meine) hinzubasteln aber im Vergleich zu einer "nativen" Anwendung ist das immer noch wesentlich unkomfortabler.
(X)HTML gibt halt einfach nicht mehr her.

Du könntest das ganze natürlich mit Flash machen :wink:

Bis neulich ...

[MrSpock]

Hallo,

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 :stupid: ?

[Grendel]

Zitat:

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 :stupid: ?

Da Mono und dotGNU noch nicht vollständig einsatzfähig sind hast Du noch Recht. Es ist aber abzusehen, daß Mono und dotGNU den ganzen .NET Klumpatsch auch für andere Plattformen als Windows + IIS verfügbar machen.
Für viele Bereiche ist es auch schon brauchbar aber man stolpert immer wieder über Fehler bzw. abweichendes Verhalten. Sieht aber vielversprechend aus.

Bis neulich ...

[bigg]

Wenn ihr viele Rechner betreuen müßt, halte ich das auch für die beste und einfachste Lösung. :)
Man ist nicht mehr auf ein System angewiesen. Bei der Routersteuerung etc. funktioniert's doch auch.

Bei Echtzeit-Anwendungen wird's da schon wieder aufwendiger.

[Grendel]

Zitat:

Zitat von bigg

Man ist nicht mehr auf ein System angewiesen.

Dafür muss man laufend die Eigenheiten irgendwelcher Browser berücksichtigen bzw. wird mit den Unzulänglichkeiten/Unmöglichkeiten von HTML konfrontiert.

Beispiel: Ich hatte bei einem o.g. Projekt ein Layout an das ich mich halten sollte. Daraus ergab sich, daß eine ComboBox max. 400px breit sein darf (ersponnene Werte). Wenn der Inhalt nun aber nicht in die 400px passt hat man ein Problem. Bei Mozilla wird der Ausklappteil der Box dem breitesten Eintrag angepasst. Beim IE, Opera, KHTML (Safari, Konqueror) hat das Ding die selbe Breite wie die Box wodurch Einträge abgeschnitten werden. Ein Problem für das es derzeit keine Lösung gibt.

Ein systemübergreifendes Toolkit (GTK, wxWidgets, Fox, etc...) macht imo mehr Sinn.

Zitat:

Zitat von bigg

Bei der Routersteuerung etc. funktioniert's doch auch.

Nur sind die Ansprüche in Bezug auf "Usability" bei einer Office-Anwendung um einiges höher als bei einer platten Konfigurationsoberfläche eines Routers (mit der man wohl kaum täglich arbeiten muss) o.ä..

Zitat:

Zitat von bigg

Bei Echtzeit-Anwendungen wird's da schon wieder aufwendiger.

Browseranwendungen sind niemals Echtzeit-Anwendungen.

Bis neulich ...

[bigg]

Zitat:

Zitat von Grendel

Browseranwendungen sind niemals Echtzeit-Anwendungen.

Die Diskussion geht mal wieder in "die richtige Richtung".
*keinbockaufsonnekinderkacke*

Von mir aus, jeder soll selbst entscheiden, wer, was, wie zusammenzimmert.
Und wenn du von PHP nicht überzeugt bist, programmierst du dein 3 Zeilenprogramm zusätzlich noch in Delphi.
Oder noch besser, schreib es mit jeder Sprache die dir bekannt ist.

PS: es gibt, wenn du so willst überhaupt keine Echtzeitsysteme.

[bate]

Ich glaube hier sollte ehr Zielorientiert gedacht werden.

1. Was für eine Anwendung soll es werden?
2. Wer soll die Anwendung nutzen und von wo? (Clients)
3. Was soll es kosten?

Wenn das beantwortet ist kann man sagen was du verwenden könntest.
Vorher wäre das wie Äpfel mit Birnen zu vergleichen.

[davar]

[quote="bigg"]
Die Diskussion geht mal wieder in "die richtige Richtung".
*keinbockaufsonnekinderkacke*

quote]

Hast Recht,

versuchen wir doch, das Thema wieder zurückzulenken in die ursprüngliche Richtung.

Da hätte ich nur gern möglichst viele Meinungen, um auch zu erfahren, wie es denn in anderen Firmen gemacht wird. Einfach nur die Antwort, über Browser oder Applikation..

[davar]

Zitat:

Zitat von bate

Ich glaube hier sollte ehr Zielorientiert gedacht werden.

1. Was für eine Anwendung soll es werden?
2. Wer soll die Anwendung nutzen und von wo? (Clients)
3. Was soll es kosten?

Wenn das beantwortet ist kann man sagen was du verwenden könntest.
Vorher wäre das wie Äpfel mit Birnen zu vergleichen.

1. Ein Kundenverwaltungssystem und eine Oberfläche für die Dateneingabe für den Onlineshop. ca. 10 Leute arbeiten mit dem Kundeverwaltungssystem (sehr oft) und etwa noch einmal so viele permanent an der Dateneingabe. Es sind schon zwei Oberflächen da, aber die sind nach Meinung aller Kollegen nicht zufriedenstellend.

2. Es werden die Arbeitsplätze in der Firma, bzw. Notebooks (Chefs) benutzt.

3. Klar, so wenig wie möglich.


Wie gesagt, es geht mir eher um die "Zukunftsorientierung".

[Grendel]

Zitat:

Zitat von bigg

Die Diskussion geht mal wieder in "die richtige Richtung".
*keinbockaufsonnekinderkacke*
[...]
PS: es gibt, wenn du so willst überhaupt keine Echtzeitsysteme.

Sorry für das OT aber DAS kann ich so nicht stehen lassen.
Doch es gibt Echtzeitsysteme aber eine Browseranwendung kann per Definition niemals dazu gezählt werden.
Erst Unfug verzapfen und dann hier rumjammern, wenn jemand einen sachlich korrigiert.

Zitat:

Zitat von bigg

Von mir aus, jeder soll selbst entscheiden, wer, was, wie zusammenzimmert.
Und wenn du von PHP nicht überzeugt bist, programmierst du dein 3 Zeilenprogramm zusätzlich noch in Delphi.
Oder noch besser, schreib es mit jeder Sprache die dir bekannt ist.

Und bitte was hat dieser Stuss jetzt an dieser Stelle zu suchen?! Fühlst Du dich beleidigt und musst mir jetzt unbedingt etwas an den Kopf werfen. Egal ob das Hand und Fuß hat oder bloß hohles Gequatsche ist.
Auch habe ich nie etwas gegen PHP gesagt. (Das Problem ist HTML) Aber man kann ja mal losschreien könnte ja passen.

Bis neulich ...

[MrSpock]

:warn:

Grendel und bigg, tragt Eure Scharmützel bitte per PN aus. Dieser Thread ist zu interessant, als dass er durch Eure Streitigkeiten verunstaltet werden sollte.

[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:

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 :stupid: ?

Da liegst Du total falsch :mrgreen:
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:

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:

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:

Zitat von Phoenix

Zitat:

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 :wink:

[Phoenix]

Zitat:

Zitat von franktron

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

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 :mrgreen:

[MaBuSE]

Zitat:

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:

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

Delphi-Quellcode:

ShowActiveFormXAbout;

belegen den anderen mit

Delphi-Quellcode:

close;

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]

:gruebel: 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.

:coder:

[davar]

@woki:

jaaaaaaaaaaaaa, sag mir nur wie :shock: :lol:

welche Bereiche muss ich mir anschauen, damit ich das auch kann? Ist es ActiveX, wie Mabuse es beschrieben hat?
Ich muss mich näher damit beschäftigen, damit auch was draus wird. Das, was Mabuse geschrieben hat, habe ich bis zur Fehlermeldung ausprobiert, für mehr Versuche fehlt mir die Zeit, ich brauche einen festen Weg, um anzusetzen..

[woki]

Zitat:

Zitat von davar

@woki:

jaaaaaaaaaaaaa, sag mir nur wie :shock: :lol:

welche Bereiche muss ich mir anschauen, damit ich das auch kann? Ist es ActiveX, wie Mabuse es beschrieben hat?
Ich muss mich näher damit beschäftigen, damit auch was draus wird. Das, was Mabuse geschrieben hat, habe ich bis zur Fehlermeldung ausprobiert, für mehr Versuche fehlt mir die Zeit, ich brauche einen festen Weg, um anzusetzen..

Es gibt sehr viel Wege um mit Delphi webbasierte Anwednungen zu entwickeln. Ich glaube, dass du mit Intraweb (ab Delphi 7 dabei, für Delphi 3 im Web recherchieren, Atozed Software) am schnellsten zu einer "Lifecoding Demo" kommen kannst, die wirklich überzeugt.
Mabuses Beispiel erscheint mir auf den ersten Blick eher nicht brauchbar für das Ziel, dass ihr erreichen wollt, denn so wie ich das, (nach ganz kurzem Blick darauf) sehe, handelt es sich hier nach wie vor um einen Rich Client, der lediglich die Anwendung in ActiveX verpackt, und dann die Gui im Internetexplorer darstellt, aber es ist nach wie vor ein Richclient, d.h. die Logik läuft nicht auf einem Server (serverseitige Komponenten, Web-Applicationserver etc), sondern läuft nach wie vor auf dem Client.
D.H. das Ganze läuft nur auf Windowscomputern, wahrscheinlich sogar nur im IE, und der Deployment und Systemadministrationsaufwand ist auch nicht reduziert.

Wenn du mehr Input brauchst, kontaktier mich mal per PN. Kann hier nicht die ganze Bedienungsanleitung für wie bringe ich Delphi in den Webbrowser abtippen.
Es geht hier um wirklich viel Geld, wenn eure Firma da jetzt die Weichen falsch stellt. Ich stehe da auch für Beratung zur Vefügung, nur für die Firma wärs dann nicht umsonst (Außer einer ersten Präsentation).

Grüsse
Woki

[MaBuSE]

Zitat:

Zitat von davar

Ich muss mich näher damit beschäftigen, damit auch was draus wird. Das, was Mabuse geschrieben hat, habe ich bis zur Fehlermeldung ausprobiert,

Welche Fehlermeldung?

Zitat:

Zitat von davar

für mehr Versuche fehlt mir die Zeit, ich brauche einen festen Weg, um anzusetzen..

Überleg mal wie viel Zeit Du bräuchtest um Deine Applikation nach PHP zu portieren.
(Falls Du das überhaupt zufriedenstellend hinbekommst)

[davar]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von davar

Ich muss mich näher damit beschäftigen, damit auch was draus wird. Das, was Mabuse geschrieben hat, habe ich bis zur Fehlermeldung ausprobiert,

Welche Fehlermeldung?

Zitat:

Zitat von davar

für mehr Versuche fehlt mir die Zeit, ich brauche einen festen Weg, um anzusetzen..

Überleg mal wie viel Zeit Du bräuchtest um Deine Applikation nach PHP zu portieren.
(Falls Du das überhaupt zufriedenstellend hinbekommst)

Sorry, das hat sich ja angehört, als hättest du Mist geschrieben. So ist es natürlich nicht, ich habe da einen Fehler gemacht, und wollte mich nicht näher damit beschäftigen. Weiss jetzt aber, wie es geht, entspricht in diesem Falle aber nicht ganz meinem Wunsch.


MfG

davar

[bigg]

[ot]

Zitat:

Zitat von Grendel

Sorry für das OT aber DAS kann ich so nicht stehen lassen.
Doch es gibt Echtzeitsysteme aber eine Browseranwendung kann per Definition niemals dazu gezählt werden.
Erst Unfug verzapfen und dann hier rumjammern, wenn jemand einen sachlich korrigiert.

*löl*
Und wie lautet die Definition Herr Prof.? *gespannt bin*

Zitat:

Zitat von Grendel

Und bitte was hat dieser Stuss jetzt an dieser Stelle zu suchen?! Fühlst Du dich beleidigt und musst mir jetzt unbedingt etwas an den Kopf werfen. Egal ob das Hand und Fuß hat oder bloß hohles Gequatsche ist.
Auch habe ich nie etwas gegen PHP gesagt. (Das Problem ist HTML) Aber man kann ja mal losschreien könnte ja passen.

ich hab's auch nicht fuer dich geschrieben, aber gut das es dich angesprochen hat :mrgreen:
Hauptsache erstmal alles zitieren *löl*


@Mr. Spock:
Hier wird die ganze Zeit über .NET gesprochen, nur interessiert es den Thread-Ersteller recht wenig.
Macht ja nix, ist ja trotzdem spannend. :roll:
[/ot]

[davar]

Zitat:

Zitat von bigg

@Mr. Spock:
Hier wird die ganze Zeit über .NET gesprochen, nur interessiert es den Thread-Ersteller recht wenig.
Macht ja nix, ist ja trotzdem spannend. :roll:

Das möchte ich so nicht stehen lassen. Auch wenn ich nicht zu jedem Beitrag was dazu sage, interessant find ich die Gespräche und lerne auch einiges daraus. Ausserdem ist dies für mich auch wegweisend, so dass ich erfahre, worauf ich mich in Zukunft konzentrieren sollte.

Übrigens sind sehr gute Beiträge dabei, wie z.B. von Alfons_G, dessen umfangreiche Erklärung ich mir ausgedruckt habe. :thumb:

MfG


davar