Look and Feel von Office 2007, welche Entwicklungsumgebung?

[Kedariodakon]

Hallo,
in Naher Zukunft sollen bei uns im Unternehmen alte in D7 entwickelte Programme neu gestaltet werden. Da es die Struktur nicht anders zulässt, müssen diese Programme für ein neues Design komplett neu geschrieben werden.
Die alten Oberflächen der Anwendungen sind alle grau, trist, überladen und ohne Benutzerführung, schlichtweg veraltet.
Zudem schreit das ganze System förmlich nach einem radikalen Schnitt! (Codemanagement, DB-Design…) (Warum, Wieso will ich jetzt hier nicht aufführen, wem es interessiert, der kann von der PM gebrauch machen)

Nach reichlicher Überlegung wollen wir nun weg von D7.
Auch scheut sich das neue dynamische Entwickler Team nicht den Umstieg auf eine andere Sprache…

So auf Anhieb fallen mir genau 2 Punkte ein, die für uns durchaus wichtig sind,

• Mehrsprachigkeit
• Datenbankanbindung (MSSQL 2005) mit möglichst vielen Features

Diese Sachen kann man natürlich auch mit D7 erreichen und sind auch erfolgreich umgesetzt.
Das was aber nun gemacht werden soll, ist eine komplett neues „Lock and Feel“ zu schaffen.

Geschaffen werden soll das „Look and Feel“ von Office 2007.
Nun meine Frage, ist das mit Delphi 2007 oder VS2005 (Visual Studio 2008) von Haus aus ohne zusätzliche Komponenten möglich (oder einer anderen Entwicklungsumgebung (Java ec..)? (.Net, win32?)
Ich habe keines der Entwicklungsumgebung und kann es daher nicht beurteilen.

Liebäugeln tun wir zurzeit sowieso schon mit einer Verwendung von C# im Bereich der Erweiterung des MSSQL2005 Servers, daher würde sich ein kompletter Umstieg auch anbieten, aber unser gutes altes Delphi haben wir auch lieb gewonnen...

Bye

[Phoenix]

Erstmal schöne Grüße in meine alte Heimat (ich bin in Rheydt geboren)

1.) Egal ob Delphi /Win32 oder C#/.NET:
Es gibt keine "IDE" die von Haus aus Office 2007-Guis erzeugen lässt. Sowohl bei Delphi als auch in der .NET Welt braucht man dafür nicht ganz billige Zusatzkomponenten.

2.) Sakura hat ein solches UI für eine seiner neueren Anwendungen gebaut. Mit Komponenten von DevExpress - in Delphi 2007. Sieht Saugeil aus, und ist reines Delphi

Also stellt sich wirklich die Frage:
Wollt ihr wirklich zu 100% alles wegwerfen und von Null anfangen? Wollt Ihr Euch dabei auch noch gleichzeitig in eine neue Technologie (und ggf. Sprache) (.NET) einarbeiten, die definitiv eine gewisse Lernkurve mitbringt?

Wenn ja: Dann viel Spass mit C# (schaut Euch aber auch mal Chrome an).

Wenn ihr aber der Meinung seid, ihr könntet Teile Eures Codes weiterverwenden, auf der Win32-Plattform bleiben könnt - dann bleibt lieber beim bekannten Delphi, stattet Euch mit der aktuellen Version 2007 sowie passenden Komponenten aus (das Visual Studio ist auch nicht gerade billig), und legt dann in der bekannten VCL-Welt ggf. auf DBx4 los.

[OregonGhost]

Aktuell gibt es als Extra für registrierte Visual C# 2005 Express-Benutzer eine Ribbon-Komponente kostenlos. Ich habe sie aber bisher nicht getestet, und ich weiß weder genau über die Lizenzbedingungen bescheid noch über die Nutzbarkeit der Komponente in den größeren Versionen. Aber das halt mal als Anhaltspunkt. Davon abgesehen kannst du dir aktuell einfach zum Testen die Beta von Visual Studio 2008 herunterladen, oder halt Visual C# 2005 Express als kostenlose Vollversion.

Für Mehrsprachigkeit gibt es in Visual Studio 2005 verschiedene Lösungen, bisher bin ich im Kleinen ganz gut damit gefahren, einfach das integrierte Ressourcen-Konzept mit Satelliten-Assemblys dafür zu verwenden, es funktioniert relativ gut und ist abgesehen davon, dass man keine "Namespaces" zur Verfügung hat, ohne für jeden eine eigene Assembly zu erstellen, ganz gut damit bedient, zumal die Ressourcen-Dateien nicht nur im integrierten Editor, sondern auch als einfaches XML-Format bearbeitet werden können. Der Zugriff gestaltet sich damit auch relativ einfach (es wird eine Klasse für den einfachen Zugriff generiert). Und, naja, dass Visual Studio 2005 eine gute Anbindung an den SQL-Server 2005 hat, sollte nicht überraschen.

Wie du schon sagtest, sollte jedoch nichts davon mit Delphi unmöglich sein.

[Bernhard Geyer]

Wenn schon komplett neue Implementierung dann biete Datenbankneutral gestallten und nicht das Anti-Pattern "Vendor Lockin" einbauen.
Sollte z.B. mit (N)Hypernate relativ einfach zu realisieren sein.

[noidic]

Ich würde die Wahl der Programmiersprache und -umgebung nicht primär davon abhängig machen, ob ich ein bestimmtes UI damit problemlos nachbauen kann. Wie teilweise schon gesagt bringt eine neue Sprache immer neue Aufwände mit sich, egal wie gut die Entwickler die Sprache schon können.
Wenn das Gesamtkunstwerk aus mehreren Einzelteilen besteht, die getrennt voneinder zu entwickeln sind, kann man auch überlegen, mehrere Möglichkeiten im ansatz zu evaluieren und sich dann für das passende entscheiden.

Zitat von Bernhard Geyer:

Wenn schon komplett neue Implementierung dann biete Datenbankneutral
gestallten und nicht das Anti-Pattern "Vendor Lockin" einbauen.

Das möchte ich so allgemein nicht unterschreiben. Warum soll man sich um die special features der einen Datenbank kastrieren, um auch andere unterstützen zu können? Ich denke das ist eine für jedes Projekt neu zu entscheidene Frage. Wir hatten auch mal den Anspruch, unsere Software DB-unabhängig zu bauen und haben dann irgendwann eingesehen, dass es mehr Sinn macht, Oracle als Vorraussetzung für den Betrieb unserer Software zu sehen, als nur im SQL-Standard zu arbeiten.
Für andere Projekte macht es durchaus sinn, soviele Datenbanksysteme wie möglich zu unterstützen.

Aber das gehört nur am Rande zum Thema.

[Kedariodakon]

Zitat von Phoenix:

Egal ob Delphi /Win32 oder C#/.NET:
Es gibt keine "IDE" die von Haus aus Office 2007-Guis erzeugen lässt. Sowohl bei Delphi als auch in der .NET Welt braucht man dafür nicht ganz billige Zusatzkomponenten.

Nun ja, dass es Komponenten dafür gibt hab ich schon herausgefunden, auch die Preise dafür variieren ziemlich stark…
Nunja, aber ohne Entwicklungsumgebung kann man sich die auch schlecht testweise anschauen…

Zitat von Phoenix:

Wollt ihr wirklich zu 100% alles wegwerfen und von Null anfangen? Wollt Ihr Euch dabei auch noch gleichzeitig in eine neue Technologie (und ggf. Sprache) (.NET) einarbeiten, die definitiv eine gewisse Lernkurve mitbringt?

Im Grunde muss das System neu entwickelt werden, daher lassen sich nur kleine Teile der Sources weiterverwenden.

Zitat von Phoenix:

Wenn ihr aber der Meinung seid, ihr könntet Teile Eures Codes weiterverwenden, auf der Win32-Plattform bleiben könnt - dann bleibt lieber beim bekannten Delphi, stattet Euch mit der aktuellen Version 2007 sowie passenden Komponenten aus

Die Frage ist wie zukunftssicher ist diese Lösung? Pattform technisch ist dies weniger das Problem, da wir nicht nur die Software verkaufen sondern auch die Hardware und den Support stellen.

Zitat von Phoenix:

das Visual Studio ist auch nicht gerade billig

Auch nicht (viel) günstiger als neue Delphi Versionen denke ich.

Zitat von OregonGhost:

Aktuell gibt es als Extra für registrierte Visual C# 2005 Express-Benutzer eine Ribbon-Komponente kostenlos. Ich habe sie aber bisher nicht getestet, und ich weiß weder genau über die Lizenzbedingungen bescheid noch über die Nutzbarkeit der Komponente in den größeren Versionen. Aber das halt mal als Anhaltspunkt. Davon abgesehen kannst du dir aktuell einfach zum Testen die Beta von Visual Studio 2008 herunterladen, oder halt Visual C# 2005 Express als kostenlose Vollversion.

Danke für den Tip, ich werde mir das auf jeden fall mal anschauen.

Im Grunde werden wir eh. Alle Entwicklungsumgebungen näher zu Gemüte führen.

Zitat von Bernhard Geyer:

Wenn schon komplett neue Implementierung dann biete Datenbankneutral gestallten und nicht das Anti-Pattern "Vendor Lockin" einbauen.
Sollte z.B. mit (N)Hypernate relativ einfach zu realisieren sein.

Das macht ev. bei kleinen Projekten und Plattform unabhängigen Projekten, wo nur Software verkauft wird durchaus Sinn, aber eine Festlegung einer unterstützten Datenbank bei größeren Projekten (wie auch in diesem Fall) hat viele andere Vorteile die die Nachteile dieser Festlegungen mehr als wett machen…

Für uns kommt daher MSSQL in Frage, da damit die Entwickler hier die meiste Erfahrung haben, sich die derzeit verwendeten Statements teilweise weiterverwenden lassen.
Dazu ist zu sagen, dass bei uns eine VS2005 Version ins Haus kommen wird, für CLR Erweiterungen am MSSQL2005, keine Ahnung ob sich solche Erweiterungen auch mit Delphi .Net umsetzen lassen, ich denke mal nicht, bin mir aber nicht sicher. Auf jeden Fall werden solche Erweiterungen Einzug in unser System erhalten, da dies wirklich ein mächtiges Werkzeug darstellt.

Wer nicht weiß, was das ist, dem kann ich den Comunity Cast (CLR) empfehlen, gibt einen kleinen Einblick in die Möglichkeiten.

Zitat von noidic:

Ich würde die Wahl der Programmiersprache und -umgebung nicht primär davon abhängig machen, ob ich ein bestimmtes UI damit problemlos nachbauen kann. Wie teilweise schon gesagt bringt eine neue Sprache immer neue Aufwände mit sich, egal wie gut die Entwickler die Sprache schon können.

Damit hast du Recht, wir werden auch nicht deswegen nun eine Entwicklungsumgebung aussuchen, nur ist es schön zu erfahren ob so was schon von Haus aus mitgeliefert wird.


Angeschaut werden sich auf jeden Fall alle Umgebungen, solch eine Entscheidung kann man nicht über Nacht fällen

[Bernhard Geyer]

Zitat von Kedariodakon:

Das macht ev. bei kleinen Projekten und Plattform unabhängigen Projekten, wo nur Software verkauft wird durchaus Sinn, aber eine Festlegung einer unterstützten Datenbank bei größeren Projekten (wie auch in diesem Fall) hat viele andere Vorteile die die Nachteile dieser Festlegungen mehr als wett machen…

Das würde ich nicht an der Projektgröße festlegen. Wir haben ein Projekt mit über 1 Mio. Quellcodezeilen und haben einen DB-Neutralen Ansatz. Nur wenn es eine Inhouse-Lösung ist oder Kundenspezifisches Projekt würde ich die Kapslung aufweichen.

Zitat von Kedariodakon:

... für CLR Erweiterungen am MSSQL2005, keine Ahnung ob sich solche Erweiterungen auch mit Delphi .Net umsetzen lassen, ich denke mal nicht, bin mir aber nicht sicher. Auf jeden Fall werden solche Erweiterungen Einzug in unser System erhalten, da dies wirklich ein mächtiges Werkzeug darstellt.

Hat nicht jemand auf der EKON 11 angemerkt das dies u.U. ein riesiges Performancegrab darstellen kann.
MS SQL-Server 2005 ist nunmal AFAIK nicht eine 100% Managed Anwendung.

[generic]

Zitat von Bernhard Geyer:

Sollte z.B. mit (N)Hypernate relativ einfach zu realisieren sein.

Ich denke du meinst Hibernate (a persistence framework).

http://www.hibernate.org/

[sakura]

Zitat von Bernhard Geyer:

MS SQL-Server 2005 ist nunmal AFAIK nicht eine 100% Managed Anwendung.

Der Server selbst ist [berhaupt nicht managed, er unterstützt lediglich die Einbindung von managed Code, und ja, das ist sehr oft ein Performancegrab und lohnt sich nur selten.

Warum? Einfach: alle übermittelten Werte müssen in .NET-Objekte umgewandelt werden, wenn die Methoden aufgerufen werden und alle zurück gelieferten Objekte müssen nach dem Aufruf zurück gewandelt werden. Es ist selten, dass dieser Overhead durch den Vorteil managed Code zu verwenden wieder ausgeglichen wird.

......

[Kedariodakon]

Zitat von Bernhard Geyer:

Das würde ich nicht an der Projektgröße festlegen. Wir haben ein Projekt mit über 1 Mio. Quellcodezeilen und haben einen DB-Neutralen Ansatz.

Ok, falsch ausgedrückt, vielleicht ist Projekt-/Systemumfang die passendere Wahl.
Jedefalls hat so eine Festlegung nicht nur Nachteile.

Zitat von Bernhard Geyer:

Hat nicht jemand auf der EKON 11 angemerkt das dies u.U. ein riesiges Performancegrab darstellen kann.

KANN, das ist der Punkt.
Es gibt Sachen, die lassen sich über CLRs sicher schön und sauberer lösen, als mit klassischen Erweiterungen per dll.
Das es nicht das Allheilmittel ist, dem bin ich mir bewust.

Zudem steht manchmal auch Performance nicht an erster Stelle.