Zitat von
mschaefer:
Wenn man etwas zwischen den Zeilen liest scheint es letztlich nicht NET oder Java zu sein, was als Entscheidungskriterium wichtig ist.Es sieht danach aus, dass die fundierten Kenntnisse der Bibliotheken über die Möglichketen bestimmen.
Das trifft die Sache im Kern. Wobei ein paar technologische Aspekte auch noch mit reinspielen, aber die sind eher zu vernachlässigen. Ich möchte da aber auch nochmal native (
Win32) Entwicklung in den Raum werfen. Auch wenn das vielleicht für die konkreten Projekte nicht zur Debatte steht, ist das nicht zu vernachlässigen. Insbesondere, wenn man früher schonmal ähnliche Projekte in Delphi realisiert hat ist der möglich Rückgriff auf bestehenden und bewährten Code nicht zu vernachlässigen. Da kann ein anderes managed Framework noch so schön sein. Am Ende zählt, wie schnell das gewünschte dabei rauskommt.
Zitat von
mschaefer:
Habe daher zwei Fragen:
1. Java: Welche Bibliotheken braucht man für eine ernstzunehmnede Windowsanwendung?
2. NET: Welche Zusatzkomponenten machen NET-Anwendungen vergleichbar zu Delphi-Native?
Wie schon erwähnt ist Java für mich keine ernst zu nehmende Alternative.
Zu 2.) Es gibt auch von DevExpress .NET Komponenten. Inklusive schöner Ribbons und Grids etc.
Telerik hat auch .NET Komponenten im Angebot, aber da muss ich zumindest vor den ASP.NET Controls warnen: Die arbeiten nicht sauber und zuverlässig miteinander zusammen und erst recht nicht mit standard ASP.NET Controls aus dem ASP.NET Ajax Toolkit. Und der Support bietet im Laufe der Zeit gerne Lösungen an, die vorherige von Telerik gelieferte Workarounds zerlegen und dadurch wieder alte Bugs einführen. Dann fällt mir spontan noch Infragistic und ComponentOne als Komponentanbieter für .NET ein. Aber eine Google Suche sollte auch noch viele andere Ergebnisse liefern.
Ich selber würde - obwohl ich noch nicht damit gearbeitet habe - eher zu DevExpress raten. Die Jungs haben einfach schon Jahrelang Erfahrungen als Komponentenanbieter sammeln können. Und zwar mit Delphi.
Und jetzt kommt Punkt 2: Der Vater von Delphi ist auch der Vater von .NET. Die MFC ticken sehr
VCL-ähnlich. Aus dem Grund versteht man als Delphianer das .NET Framework ziemlich schnell und hat zumindest im Bereich von Windows Forms kaum Umstellungsaufwand und im Bereich von WPF hält sich das auch Grenzen (ob das nun Text-
DFM's oder XAML-Dateien sind.. who cares wenn da nun auch Animationen oder Texturverweise drin stecken?). Das gleiche gilt natürlich auch für die Drittanbieter und deswegen würde ich persönlich eher DevExpress aufgrund der langen Delphi-Erfahrung zutrauen, hochqualitative Komponenten und sehr guten Support zu liefern (Nein, ich bekomme leider keinen Cent dafür).
Will heissen: Als Delphianer auf .NET zu wechseln ist um längen einfacher, als sich in Java einzuarbeiten. Im Prinzip ist das für uns ein alter Hut mit neuem Logo drauf und etlichen Features mehr. .NET reduziert auf
ADO.NET und Windows Forms ist das, was Delphi heute sein könnte, wenn man etwas mehr in Databinding und eine erweiterete
VCL investiert hätte.