Nativer Programmcode

[nahpets]

Hallo,

Zitat:

Zitat von Bernhard Geyer

Für einfache RAD mit direkter DB-Anbindung der Sensitiven Controls ist es mit Delphi schneller. Aber sobald es auf Multi-DB-Support geht ist man mit JDBC einfacher dran. Die nativen DB-Zugriffskompos diverser DBs haben unter Delphi eine höhere diversität als unter JDBC.

Wie meinst Du das?

Ich habe mir vor Jahren angewöhnt bei Datenbankanwendungen alle SQL's in eine Datenbanktabelle zu legen und aus dem Programm nurnoch die SQL's per ID aus dieser Tabelle zu lesen. Alles Andere geht über ADO (ist sicherlich nicht immer das Leistungsfähigste, aber für mich das Unabhängigste - mit der BDE war vieles einfacher, aber das ist halt Schnee von gestern). In einer INI steht der Connectionstring und kann ggfls. über die Applikation geändert werden. Damit bin ich datenbankunabhängig. Wird die Datenbank gewechselt, muss ich den Connectionstring ändern, gibt's dann Inkompabilitäten, weil SQL nicht gleich SQL ist, muss ich die SQL's in der Datenbank anpassen und brauche nicht an das Programm. So kann ein Programm aber auch bei verschiedenen Kunden gegen verschiedene Datenbanken laufen und ich brauche nicht für jeden Kunden eine eigene Programmversion.

Webapplikationen hab' ich (firmenintern) inzwischen eine ganze Reihe, ausschließlich mit Delphi geschriebene ISAPI-Dll's und 'nen eigenen Webserver dank Indy-Komponenten. Das Ganze läuft auf unterschiedlichen Server und auch noch auf den lahmen Büchsen, die man als Admin immer irgendwann irgendwo über hat. Der Webserver passt immer noch zusammen mit seiner Konfigurationsdatei auf eine Diskette und muss nicht mal installiert werden: Doppelklick und läuft. Per USB-Stick kann man damit ggfls. beim Kunden auf einem beliebigen Rechner mal eben eine kleine Webapplikation vorführen. Klar: Für 'nen Webauftritt a la WDR, Google, diversen Zeitungen, eBay, Amazon und sonstwas reicht das nicht.

Zitat:

Zitat von inherited

Wir kommen also im Großen und Ganzen darüber überein, dass es immer darauf ankommt, was man machen möchte. Wirklich neu ist diese Erkenntnis ja nicht.

Ja, natürlich, womit man entwickelt, ist immer Geschmacksache, wie beim Auto, fahren tuen alle aber...

Schön fände ich, wenn die, die sich hier an der Diskussion beteiligen einfach mal schreiben würden:

Zitat:

Ich nehme Delphi weil...

unabhängig davon, ob andere das auch können, etwas besser können oder eventuelle Fehler in Delphi bei bestimmten Sachen dagegensprechen: Sprich, was führte in Summe dazu, sich (weitgehend) für Delphi zu entscheiden?

Stephan

[S20000]

@divBy0

Ist ja ne berechtigte Frage. Ich bin/war ein kompletter Neueinsteiger
in der objektorientierten Programmierung und habe davor nur ein wenig
C programmiert. In meiner Abteilung ist Delphi bereits etabliert und
es war auch schon eine Version vorhanden. Außerdem konnte ich
relativ schnell einsteigen, und das hat mir gut gefallen.

[Reinhardtinho]

Das sieht doch nach einer schlüssigen Begründung aus.

[divBy0]

Darauf wollte ich ja hinaus. Das ist doch die Begründung warum du dich für Delphi entschieden hast. :-D

[nahpets]

Zitat:

Zitat von S20000

Ist ja ne berechtigte Frage. Ich bin/war ein kompletter Neueinsteiger
in der objektorientierten Programmierung und habe davor nur ein wenig
C programmiert. In meiner Abteilung ist Delphi bereits etabliert und
es war auch schon eine Version vorhanden. Außerdem konnte ich
relativ schnell einsteigen, und das hat mir gut gefallen.

Und das sind Gründe, die sollte ein guter Chef verstehen und akzeptieren.

Stephan

[S20000]

:-) Stimmt schon, das ist ne Begründung. Aber im gleichen Zuge
wollte ich halt ein paar nachvollziehbare Vorteile von
Delphi aufführen.

[Bernhard Geyer]

Zitat:

Zitat von nahpets

Wie meinst Du das?

- Z.B. das Username/Passwort einmal als extra Property (mit unterschiedlichen Namen) verfügbar ist, einmal in irgendein ConnectionString codiert werden muss und dann manchmal im Param-Stringliste gespeichert wird
- Param werden nicht immer über Paramliste gehandhabt sondern teilweise über andere Methoden (DeclareVariable bei DOA-Komponenten)
- ...

[nahpets]

Zitat:

Zitat von Bernhard Geyer

- Z.B. das Username/Passwort einmal als extra Property (mit unterschiedlichen Namen) verfügbar ist, einmal in irgendein ConnectionString codiert werden muss und dann manchmal im Param-Stringliste gespeichert wird
- Param werden nicht immer über Paramliste gehandhabt sondern teilweise über andere Methoden (DeclareVariable bei DOA-Komponenten)
- ...

Okay, da hab' ich auch schon manche Stunde geflucht bis bei Applikation X die Anmeldung funktionierte, obwohl ich's doch eigentlich genauso gemacht hatte wie bei A, B, C....
Und der Eine ruft die Login-Routine der Komponente auf, der Andere nicht, der Eine benutzt die dort zugewiesenen Werte, der Andere nicht, der Eine will "USERNAME" der Andere "USER NAME"...
Heute kommt die Anmeldung mit in den Connectionstring, der wird dann halt verschlüsselt gespeichert.

Zitat:

Zitat von S20000

Stimmt schon, das ist ne Begründung. Aber im gleichen Zuge
wollte ich halt ein paar nachvollziehbare Vorteile von
Delphi aufführen.

Hoffe, wir haben Dir trotz aller Meinungsverschiedenheiten genügend Stoff zu Chefüberzeugung :wink: geliefert, der muss das hier ja nicht lesen. 8)

Stephan

[S20000]

Ja, so eine Diskussion legt ja dann auch
verschiedene Ansichten dar.

VB ist bei uns in der Firma noch vertreten (.NET), das wäre
doch ein Beispiel für eine Laufzeitumgebungs-abhängige Variante oder?

[mkinzler]

Ja benötigt entsprechende .Net Laufzeitumgebung