Womit sollten heutzutage Datenbankanwendungen geschrieben werden, die zukunftssicher sind?
am besten gar nicht. Schau dir nur mal die letzten 10 Jahre an was aus VB (nicht .Net), Kylix und Interbase wurde.
Wichtig wäre, dass ohne große Kosten kommerzielle Software damit geschrieben werden kann. Ich kenne mich mit den Lizenzen da nicht so gut aus. Beispielsweise, ob man das kostenlose Visual Studio Express kommerziell nutzen darf.
Was soll das? Die 1000€ für eine
IDE bzw. 5.000-7.500€ (einfach mal ins blaue geschätzt) für einen Arbeitsplatz sind Peanuts! Was ins Geld geht sind die Personalkosten! Diese kann man mit sinnvollen Arbeitsumgebungen zwar nicht reduzieren aber wesentlich mehr herausholen! Wenn du "billig" programmieren willst, dann verwende [Übertreibung] Turbo Pascal 5.5 oder Vb 6.0 [/Übertreibung]
Oder verwende Notepad und einen Kommandozeilencompiler. Sehr billig, die Entwicklung wird aber ewig dauern....
Programmiersprachen/Frameworks
Kommt auf deinen Geschmack und auf die vorhandenen Ressourcen an. Wenn du ein großes Entwicklerteam hast, die an einer Anwendung arbeiten müssen, ist .NET durch das Assembly-Konzept jeglichen
Win32-Sprachen im VOrteil. Weiterhin wirst Du einfach wesentlich schneller genügend Mitarbeiter finden.
- WPF (neuer als WinForms, doch vermutlich auch bald veraltet)
OT:
??? Habe ich was nicht mitbekommen? In den letzten WOchen wird als Gerücht in div. Blogs immer von Silverlight gesprochen, das eingestellt werden soll, aber warum denn WPF? Dann kann Microsoft mit .Net endgültig einpacken....
Wie bei den Programmiersprachen: Es kommt darauf an. Div. Firmen lassen kein Oracle auf ihre Server, andere keine MS
SQL usw. Das ändert sich aber auch immer i.d.R: mit dem Personalwechsel bei Systemadmin
Da werden schon mal eben kurz eine Serverfarm mit funktionierendem Linux-Mailserversystem auf Exchange umgestellt
Was wichtig wäre:
* Die Businnesslogik sollte getrennt von allem erarbeitet werden, d.h. Einsatz einer entsprechenden Beschreibungssprache (
UML) um bei einem ggf. notwendigen Systemwechsel zumindest das Businessmodell retten zu können.
* schlägt in die selbe Kerbe: Schichtenaufbau der Anwendung, d.h. die Schichten
GUI, Businessmodell und Datenbank greifen nicht direkt aufeinander zu sondern über definierte Schnittstellen (da gibts auch jede Menge Patterns dazu). Damit lässt sich zum einen die Datenbank relativ "einfach" austauschen, zum anderen gäbe es ggf. die Möglichkeit eine andere
GUI anzusprechen (z.B. mit einem Delphi-BOM eine .NET Oberfläche "bedienen")
* Vergiss auf übermorgen zu schauen: Du weißt nicht mal was morgen passiert. Meine Bekannten, die sich in der Branche auch auskennen, machen mich immer dumm an: Wer mit Delphi programmiert, der gehört vor Gericht. War aber vor 10 Jahren auch schon so. Je vorsichtiger Du irgenwelche Entscheidungen angehst, je länger (und teurer) wird im Endeffekt deine Entwicklung werden. Das heißt jetzt nicht renn blind durch die Gegend, sondern es gehört einfach ein gesundes Maß dazu. Und Fehlentscheidungen gehören hier wie überall einfach dazu....
GRüße