Neues Projekt - Neue Programmiersprache?

[Thomas Sparenberg]

Hallo!

Für ein neues Projekt welches Anfang 2003 starten soll muß ich heute einige Entscheidungen treffen. Vielleicht kann mir jemand helfen.

Bis jetzt setzen ich Delphi 6 mit einer Paradox-Datenbank ein.

Nun soll das neue Projekt auf Basis des MS-SQL-Servers aufsetzen. Weiterhin soll als "Report-Generator" Access verwendet werden.

In dem Projekt werden Daten aus einer Anlagensteuerung ermittelt und in die Datenbank eingetragen. Ich bin mir jetzt nicht mehr so sicher ob ich nicht VB.net als Programmiersprache einsetzen sollte um auch in 5-10 Jahren den Programmcode nicht vollständig überarbeiten bzw. ersetzen zu müssen.

Über eine Entscheidungshilfe währe ich sehr Dankbar.

mfg Thomas

[Jörg Wegener]

Hallo Thomas,<br>

diese Entscheidungen zu treffen, fällt wohl keinen von uns leicht. Die Richtige Programmiersprache und Entwicklungsumgebung zu wählen ist ein entscheidener Schritt.

Mit .NET ist sicherlich ein guter Schritt getan, da die Zukunft unter Windows ganz Sicher .NET sein wird. Leider kann man sich nicht in jeder Programmiersprache vor Veränderungen schützen. Selbst der eigene Programmierstil ändert sich im Laufe der Zeit. Die Änderungen, die VB.NET erfahren hat, waren sicherlich notwendig (und höchste Zeit).

Alternativ dazu kann man sicherlich auf Delphi.NET warten, da vorhandene Kenntnisse genutzt werden können. Ich kann mir aber vorstellen, das gerade Delphi in nächster Zeit starken Veränderungen unterworfen wird, da Anpassungen an .NET unumgänglich werden. (Ich frage mich wie in die Zuammenarbeit mit Delphi-Strings und .NET-String laufen wird, wo Delphi-String schon nicht mal kompatibel zu den Windows strings/chars[] waren).

Meine neuen Projekete erstelle ich ausschließlich mit C#, was eigentlich sehr angeehm zu prgrammieren ist, da es sehr nah an Delphi und Java angelehnt ist.

Schwierige Entscheidung aber auch..

[Bernhard Geyer]

Hallo Thomas,

Wieso soll bei deinem neuen Projekt Access als Report-Generator eingesetzt werden? Falls es darum geht nur dem Entbenutzer eine Möglichkeit an die Hand zu geben seine Reports persönlich Graphisch zu gestalten, so kannst Du ja die Möglichkeiten des MS-SQL-Servers verwenden um die Auswertung vorzubereiten (Stichwort: OLAP-Services), so kannst Du als Reportgenerator auch Excel verwenden (welches evtl. in deinem Bereich die Benutzer besser können).

Was die sonstig nötige Programmierung anbetrifft ist hier Delphi (trotz noch nicht vorhandener .NET-Unterstützung) evtl. die bessere Möglichkeit. Falls die Daten deiner Anlagensteuerung z.B. über eine serielle Schnittstelle hereinkommen sind die unter Delphi verfügbaren Komponenten sehr viel einfacher (und evtl. auch Leistungsfähiger) als die MS-Komponenten für die serielle Schnittstelle.

Und für den Zugriff auf einen MS-SQL-Server ist zwar Delphi nicht die Nr. 1 aber auch sehr gut zu verwenden (mit oder ohne ADO-Express-Komponenten).

@Jörg: Wieso sollen die Delphi-Strings nicht kompatibel mit den Windows-Strings sein. Ich habe damit keine Probleme (im gegensatz zu den unter Visual-C++ vorhandenen mehreren String-Klassen für die MFC/ATL-Bibliothek

[Thomas Sparenberg]

Vielen Dank für euere Hinweise und Anregungen!

@Bernhard: Die Steuerungen koppel ich über OPC an. Ich möchte Access als Reporttool verwenden da es bei uns schon seit einigen Jahren in diesem Bereich als Reporttool im Einsatz ist.

Antrieb für ein Umstieg auf VB war der Gedanke "Coderecycling". Leider ist VBA noch nicht .net kompatibel und so frage ich mich ob ich hier überhaupt ein Vorteil ergibt.

Ein weiterer Grund ist die Unsicherheit über das Fortbestehen von Delphi. Die Umstellungen in Delphi 6 sind Borland ja auch nicht so gut gelungen - was wird dann erst bei .NET.

Vielleicht könnte Herr Kosch hier meine Bedenken entkräften. Ich glaube jedoch auch bei Ihnen einen gewissen negativen Unterton zu heraus zu höhren.

mfg Thoma

[Mario.Noack]

Hagen ist ja da recht optimistisch ( http://www.entwickler-forum.de\webx?128@@.ee8c60f ).<br>
Ich Glaube aber auch nicht an das Allheilmittel Delphi 7. Zudem soll Delphi und Kylix ja eine gewisse Kompatibilität haben und nun kann Kylix auf einmal C++. Das ganze System wird immer Komplexer...<p>
Grüße, Mario Noac

[Andreas Kosch]

Hallo,

nachdem ich extra angesprochen wurde, kann ich mich nicht mehr durch Schweigen aus der Affäre ziehen :-)

&gt;..Unsicherheit über das Fortbestehen von Delphi..

Die Kernfrage ist Heute, ob man <b>nur</b> für Windows entwickelt. Wenn die Frage mit "Ja" beantwortet wird, gibt es zu .NET keine Alternative. Und da die verwendete Sprache in .NET dank den Klassen aus dem .NET-Framework völlig egal ist, hat auch die Entscheidung für eine bestimmte Sprache einen geringen Stellenwert.

Dies gilt auch für Delphi .NET, wobei man dort zusätzlich eine weitere Entscheidung treffen muss: <br>
a) nutzt man die VCL für .NET, oder <br>
b) nutzt man nur die Klassen aus dem .NET Framework <br>
Immer dann, wenn man nur für Windows (.NET) entwickelt, macht es keinen Sinn, ein neues Projekt mit der .NET-Fassung der VCL zu beginnen - denn damit handelt man sich einige Nachteile ein: <br>
a) Man muss dann immer bei Delphi bleiben <br>
b) Man muss auf das nächste Delphi-Upgrade warten, um Änderungen am Betriebssystem nutzen zu können (siehe XP-Styles, die auch erst ab Delphi 7 nutzbar sind).

Wenn man aber auf die VCL (für .NET) verzichtet und nur mit den Klassen aus dem .NET-Framework arbeitet, ist Delphi eine ganz "normale" .NET-Sprache neben VB.NET und C#. Da die .NET-Fassung von Delphi außerdem erst im nächsten Jahr erscheint, kann man Heute noch nicht sagen, wie gut die Anpassung an .NET gelungen ist. Es spricht doch aber nicht dagegen, bereits Heute mit VB.NET oder C# anzufangen. Auch dann, wenn man später zu Delphi .NET wechselt, kann man die bereits fertigen Teile als Assemblies ins Delphi .NET-Programm einbinden (eine Anwendung darf ja aus Teilen bestehen, die in verschiedenen Sprachen geschrieben wurden).

Da .NET über <i>P/Invoke</i> und <i>COM Interop</i> auch "alte" DLLs und COM-Objekte einbinden kann, macht es Sinn, in konkreten Einzelfall auf die Fähigkeiten von Delphi 5/6/7 zurückzugreifen. Die Entscheidung, wo eine bestimmte Funktion umgesetzt wird, würde ich pragmatisch treffen: Immer mit der Umgebung, mit der die Aufgabe am einfachsten gelöst werden kann.

P.S:

&gt;..Zudem soll Delphi und Kylix ja eine gewisse Kompatibilität <br>
&gt;haben und nun kann Kylix auf einmal C++.

In der Tat unterwirft sich Delphi seit der Version 6 dem Prinzip des kleinsten gemeinsamen Nenners. Für das angekündigte Delphi .NET spielt das jedoch nur dann eine Rolle, wenn man die Delphi-spezifischen Teile (wie die VCL .NET) verwendet. Solange man sich bei Delphi .NET auf die Klassen aus dem .NET-Framework beschränkt, kann Borland Dank der CLR "keinen Unsinn machen" :-)

[Thomas Sparenberg]

Hallo!

Vielen Dank an alle! Ich glaube ich sehe jetzt klarer.

@Hr.Kosch: Vielen Dank für Ihre Stellungnahme! Noch eine Frage: Wird man von Ihnen demnächst auch VB.net-Bücher treffen :-)?

mfg Thoma

[Andreas Kosch]

Hallo,

&gt;Wird man von Ihnen demnächst auch VB.net-Bücher treffen :-)?

eher auf gemischte VB.NET/C#/Delphi.NET-Bücher. In meinen Sessions und Workshops auf der <i>dot.net-Konferenz</i> im Juli diesen Jahres waren bereits alle Beispiele in 2 Versionen (VB.NET und C#) enthalten. Es kommt in einem Buch eventuell noch eine 3. Sprache hinzu (Delphi .NET)

[Mario.Noack]

In sofern habe ich natürlich für die Zukunft mit Delphi dann ein Problem, oder etwa doch nicht?<p>
Meine alten D5/6 Anwendung müssen bei Übernahme auf Delphi 7 ja auf der VCL-Schiene weiterfahren, darauf basieren ja auch die ganzen Komponenten. Eine Übernahme auf Delphi.Net Klassen wäre ja dann fast Neuprogrammierung...<p>Eine neue Anwendung kann ich dann auf den Net-Klassen aufbauen, wobei ich dann meine ganzen VCL-Komponenten zur Seite legen muss?<p>
Wird es also in Zukunft VCL, CLX und Net-Framework-Projekte geben

[Andreas Kosch]

Hallo Mario,

&gt;..für die Zukunft mit Delphi dann ein Problem, oder etwa doch nicht?

ich würde das nicht so düster sehen. Auch Microsoft empfiehlt für "seine Leute" (C++, VB6), bestehende Anwendungen zu belassen und nur Erweiterungen bzw. neue Anwendungen mit .NET zu beginnen. Das gleiche gilt auch für unsere bestehenden Delphi-Anwendungen - hier gibt es keinen Grund, die VCL-Anpassung nicht zu nutzen, um den Aufwand für die Programmpflege zu begrenzen. Der Verzicht auf die VCL für .NET macht nur bei neuen Anwendungen Sinn.

&gt;..wäre ja dann fast Neuprogrammierung...

Das ist ein generelles Problem, das nicht nur uns Delphianer betrifft. Zum Beispiel gibt es in <i>Visual Studio .NET</i> einen Wizard, der alte Visual Basic 6-Anwendungen in eine VB.NET-Anwendung transformiert. Aber das ist nur alter Wein im neuen Syntax-Schlauch - wenn die Anwendung die Vorteile von .NET richtig ausnutzen will, müsste sie auch dann neu geschrieben werden.

&gt;Wird es also in Zukunft VCL, CLX und Net-Framework-Projekte geben?

Borland hat angekündigt, dass beim zukünftigen Delphi .NET die Linux-Anpassung und somit die CLX entfällt (d.h. Delphi .NET wird ein zusätzliches Produkt zum bisherigen Delphi). Somit haben wir dann nur die Wahl zwischen der VCL .NET und dem .NET-Framework, wobei die VCL .NET ebenfalls auf dem Framework aufsetzen wird und nur die gewohnten Eigenschaften und Methoden zusätzlich implementiert (siehe ADO Express-Komponenten zu nativen ADO-Objekten).

Da mittlerweile auch in der .NET-Welt eine Community entstanden ist, die FreeWare-Komponenten für das .NET-Framework bereitstellt, ist zukünftig die "Trefferquote" bei der Komponenten-Suche immer dann höher, wenn man nicht auf VCL .NET-Komponenten beschränkt ist (es wird auch zukünftig sehr viel mehr VB.NET/C#-Leute geben als Delphi-Entwickler)