Vorteile von Delphi gegenüber C#

[Alfredo]

Zitat:

Es gibt noch kaum noch Vorteile von Delphi gegenüber C# und auch kein Alleinstellungsmerkmal.

Im Bereich des Zugriffs auf Datenbanken die nicht von MS stammen sehr wohl.

ADO.Net ist von seinem Grundkonzept m.E. für einen Praktiker eine absolute Fehlkonstruktion.

Gruß
Alfred

[Bernhard Geyer]

Zitat von Alfredo:

ADO.Net ist von seinem Grundkonzept m.E. für einen Praktiker eine absolute Fehlkonstruktion.

Wieso?

[Alfredo]

Zitat:

Wieso?

Das asynchrone Modell lautet wie folgt:


Daten werden aus der Datenbank abgefragt, in das Dataset geladen und
die Verbindung wieder geschlossen und die Daten offline weiterbearbeitet.

Viel Spass beim zurückschreiben der Daten.


Zurückblättern in einer Datenbank geht auch nur mit Tricks.


Gruß
Alfred

[HeikoAdams]

Nu muss ich hier auch mal meinen Senf dazu geben 8)

Seit meinen Chefs vor einigen Wochen jemand den Floh ins Ohr gesetzt hat, das Delphi total veraltet, und sowie schon so gut wie tot sei (LÜGE!!) und mit C# angeblich alles viel einfacher, schöner und schneller geht, "darf" ich mich jetzt auch mit dieser "Sprache" auseinander setzen. Meine Meinung zu C# ist eindeutig:

C# verleitet, nein, es nötigt einen dazu, unübersichtlichen Code zu fabrizieren, da man immer und überall Variable deklarieren kann und mit Klammer, Ausrufezeichen etc um sich werfen muss, anstatt entsprechende Schlüsselwörter zu verwenden. Also eher was für schreibfaule Programmierer als für gewissenhafte Softwareentwickler Ich finde Delphi ist da durchdachter, da es einen dazu zwingt, wenigstens halbwegs lesbaren Code zu schreiben. Gegen fehlende oder katastrophale Formatierungen von Sourcecode is ja noch kein Kraut gewachsen.

Ich muss ehrlich sagen, das ich bislang keinen objektiven Vorteil von C# gegenüber Delphi gefunden habe.

[Elvis]

Zitat von Bernhard Geyer:

Zitat von Alfredo:

ADO.Net ist von seinem Grundkonzept m.E. für einen Praktiker eine absolute Fehlkonstruktion.

Wieso?

Das hört man fast nur von Leuten, die vorher irgendwelche Connections auf irgendwelche Forms oder Datamodules gezogen haben.
Das funktioniert mit ADO.Net natürlich überhaupt nicht gut. Aber ADO.Net ist auh entworfen wurden um sinnvollen Datenzugriff zu vereinfachen. Nicht solchen unwartbaren Klickibunti-Connection-auf-den-Designer-ziehen Krempel.

[HeikoAdams]

Zitat von hanspeter:

Es gibt noch kaum noch Vorteile von Delphi gegenüber C# und auch kein Alleinstellungsmerkmal.

Doch:

• native Compiler -> keine bloated Runtime notwendig
• keine Runtime = eine potentielle Fehlerquelle weniger
• einfach zu erlernen
• strukturierter Aufbau des Sourcecode
• Quellcodes sind für dritte leicht lesbar

Also, wenn ich noch länger nachdenke, dann fallen mir sicher noch einige Vorteile ein 8)

[mkinzler]

Irgendwie wird hier nicht die Sprache sondern eher die Platform verglichen

[Bernhard Geyer]

Zitat von Alfredo:

Daten werden aus der Datenbank abgefragt, in das Dataset geladen und
die Verbindung wieder geschlossen und die Daten offline weiterbearbeitet.

Viel Spass beim zurückschreiben der Daten.

Zurückblättern in einer Datenbank geht auch nur mit Tricks.

Wir haben in unserer App genau sowas implementiert und sind glücklicherweise seit einiger Zeit TDataset und DB-Senstive Controls los. Haben damit auch einige Performancelücken lösen können die durch DB-Sensitive Controls und rückwärts scrollbare große Datenmengen (teilweise mit DBGrid-Bindung) verursacht wurden (haben DB's >> 10 GB im Einsatz) gelöst.

Aber AFAIK gibt es für Prototyp-Erstellung mittlerweile in .NET (2.0) eine Delphi-Like DB-Bindung.

[Alfredo]

Hallo Elvis,

dann schreib doch mal mit ADO.NET eine Lagerbuchhaltung oder ein
Kassenbuch.

Es gibt eine Vielzahl von praktischen Beispielen, bei denen ADO.NET
zu erheblichen Problemen bei der Realisierung führt.

Greif mal direkt auf Firebird zu.

Warum soll ich mir dass alles antun, wenn eine einzige Komponete
im Zusammenspiel mit der Datenbank dies alles "just in time"
erledigt.

Für was gibt es SQL-Befehle die die Datenmenge im Dataset ohne
Probleme auf ein Minimum beschränken.


Gruß
Alfred

[hanspeter]

Zitat von HeikoAdams:

[*] keine Runtime = eine potentielle Fehlerquelle weniger

Unser Projekt benötigt mehr als ein Dutzend dll.
Teilweise in unterschiedlicher Konfiguration. (Freischaltmodell)
Da muss mit den runtime BPL von Delphi gearbeitet werden.
Die BPL Hölle ist ein vielfaches der dll Hölle.
Beherrschbar ist das Ganze nur, wenn vor einem Update das
gesamte Projekt komplett neu kompiliert wird.
Vorher alle DCU und bpl löschen.
Bei uns erledigt das ein Buldserver. Der läuft jede Nacht und benötigt mehr als eine Stunde.
Ein Problem mit der Net - runtime hatte ich noch nicht.
Ich rede allerdings von einer abgesicherten Serverumgebung.

Gruß
Peter