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
