Welches Entwicklungssystem (C#, C++,???)
Hallo,
wir haben im Prinzip 3 Softwarepakete, eines noch unter DOS, zwei unter Windows. Alle Projekte sind im Prinzip Branchenlösungen und arbeiten mit Datenbanken. Die beiden Windowsprogramme verwenden entweder eine Access DB Engine oder einen MS SQL Server. Unter Windows wurde alles mit
VC++ (aktuelle Version), Stingray Studio und LL14 entwickelt.
Ein Kernstück in unseren Windows Programmen ist ein aufwendiger DB Browser der auf Stingray Studio aufsetzt. Im weitesten Sinne sollten alle 3 Programme zusammenarbeiten und manche Stammdaten aus der SQL DB gemeinsam verwenden können.
Nun steht eine Umsetzung des DOS-Programms auf Windows an. Die entscheidende Frage ist nun, nehmen wir VC++ oder C#.
Für VC++ sprechen die vorhandenen Tools (Stingray) und unser fertiger DB Browser (war mal einige Monate Arbeit...). Unter C# haben wir bisher nur ein kleines Programm entwickelt und weder Tools noch große Erfahrung.
IMHO ist C# die modernere Variante, aber rechtfertigt das den zu erwartenden Mehraufwand bei der Entwicklung?
Beste Grüße
Markus aka SatMAX
Hallo SatMAX,
redest du von managed C++ oder von unmanaged C++?
Ersteres unterscheidet sich (in Reinform) unterm Strich gesehen nicht allzusehr von C# - ein Umstieg sollte größtenteils mit Syntaktischen Umgewöhnungen einhergehen, da ja die ganzen .NET Bibliotheken die gleichen sind.
Von letzterem viele der Umstieg deutlich schwerer, da teilweise auch vollkommen neue Paradigmen (keine Pointer mehr im herkömmlichen Sinne, GC und damit komplett anderes Resourcenmanagement usw.) dazu kommen würden.
Allerdings kann man "unsauberen" Code sowohl mit C# als auch mit C++ schreiben - viel wichtiger also ist "guter" Codingstyle und bestenfalls auch konsequentes Unittesting.
Meiner Erfahrung nach ist C++ Code aber häufig "unsauber" geschrieben - d.h. ellenlange Methoden, "Monsterklassen", viele Methoden mit mehr als 3 Parametern, keine sprechenden Namen etc.
Für VC++ sprechen die vorhandenen Tools (Stingray) und unser fertiger DB Browser (war mal einige Monate Arbeit...).
Der DB Browser wäre ja bei einem Umstieg auf C# nicht "verloren", oder?
Das Stingraystudio sagt mir persönlich jetzt nichts - ich gehe mal davon aus, dass es sich bei beiden Dingen um Entwicklungswerkzeuge handelt?!?
Wichtig ist auch, ob alter Code "recycelt" werden soll, d.h. ob einige C++ (nicht COM) Bibliotheken weiterverwendet werden müssen - das würde C# nur behindern.
Hallo winSharp,
ist alles unmanaged c++. Die beiden bestehenden Windows Programme würden aber kurzfristig ohnehin nicht umgestellt werden.
Es wäre halt tlw. einfach bestimmte Code Teile zu verwenden. Insbesondere der DB Browser und Stingray Objective Studio (unser DB Browser setzt darauf auf).
Stingray Objective Studio gibt es nicht für C#, somit wäre auch unser DB Browser verloren. Die Frage ist, braucht man das unter C# überhaupt noch. .Net und C# bieten doch schon einiges mehr als VC++ vor 8 Jahren....
Wenn C# , kommt sicher als nächstes die Frage WPF oder Windows Forms.
Es wäre halt tlw. einfach bestimmte Code Teile zu verwenden.
Wie ordentlich bzw. wie wartbar ist denn dieser Code?
Sofern es sich um "sauberen" handelt, wäre ein Rewriting / Redesign ja nicht wirklich sinnvoll.
Und das wäre bei einer Migration zwingend erforderlich.
Insbesondere der DB Browser und
> (unser DB Browser setzt darauf auf).
Der Objekt Browser ist also eine Art Steuerelement?
Dann kann man ihn wiederverwenden: Einen Wrapper in managed C++ schreiben und wie eine .NET Klasse verwenden - bei Bedarf lässt er sich dann später einfach austauschen.
Die Frage ist, braucht man das unter C# überhaupt noch.
Nach dem Überfliegen der Seite: Nicht unbedingt. VS und die FCL bieten hier schon einiges an. Nichtsdestotrotz finden sich allerlei Komponenten auch bei Drittanbietern.
Wenn C# , kommt sicher als nächstes die Frage WPF oder Windows Forms.
Das wird aber nicht zeitunintensiv in puncto Schulungen. Der Schritt von MFC auf WPF ist IMHO nicht gerade der leichteste (insbesondere, wenn man bei der Gelegenheit auch noch auf eine managed Programmiersprache wechselt).
Wie gut sind denn die Kenntnisse des Teams zum Thema CLR / FCL / C#(oder sogar WinForms / WPF) bzw. .NET im Allgemeinen?
Bzgl. der Frage ob WinForms oder WPF gab es auf der Heise Developer Seite folgenden netten Artikel von Dr. Schwichtenberg WPF versus Windows Forms - Die Diskussion
Gruss, DaMoe
folgenden netten Artikel von Dr. Schwichtenberg
IMHO ist der aber recht einseitig geschrieben bzw. lässt einen entscheidenen Punkt einfach weg: Die eigentliche Entwicklung der UI-Logik.
Hier bietet die WPF - zwar mit einem zugegebenermaßen erschlagenden Einarbeitungsaufwand - meiner Ansicht nach die meisten Vorzüge vor WinForms. Animationen, 3D, Shadereffekte usw. sind da nur eine nette Beigabe.
Und gerade diese netten Beigaben werden überall gezeigt, und verhindern das
die Leute sich mit den überragenden DataBindingfähigkeiten und der UI-Trennung
beschäftigen, weil jeder Entscheider dann sagt:
"So nen Spielkram braucht der Kunde nicht!".
Ich glaube, die Entscheidung ob C++ oder C# kann euch niemand abnehmen. Meiner Meinung nach geben sich die beiden Sprachen nicht viel im Bezug auf modern oder nicht modern. Die Frage ist eher das Einsatzgebiet.
Ich persönlich bevorzuge zur Anwendungsentwicklung mit moderner GUI auf jeden Fall C#, ganz einfach deswegen, weil ich mich damit auskenn. Mit C++ kann man aber das gleiche machen, wenn man weiß wie.
So wie ich das sehe, habr ihr bei euch bereit KnowHow für C++. Wie sieht es mit dem KnowHow für C# aus? Die Einarbeitszeit ist ein nicht zu vernachlässigender Kostenfaktor. Wiederverwendbarkeit von bestehenden Komponenten hast du ja bereits genannt, wobei man auch mit ein paar Tricks unmanaged Controls in .NET verwenden kann. Aber das ist auch wieder mit Aufwand verbunden.
Zu allererst müsste man analysieren, warum das Dos-Programm umgestellt werden soll. Liegt es an neuen Anforderungen? Soll es einfach eine modernere Oberfläche bekommen? Läuft es auf modernen Betriebssystemen nicht mehr? Und so weiter. Wenn nur die Oberfläche modernisiert werden soll, kann man sich auch überlegen, ob man als Kern das alte Programm beibehält und nur eine neue Oberfläche andockt. Es ist zwar immer recht schön, wenn eine Software komplett neu gestrickt wird um bessere Programmier-Standards verwenden zu können, aber Geld verdienen kann man damit in meinen Augen nicht wirklich.
Ich persönlich halte nicht viel von irgendwelchen Sprachumstellungen nur weil jemand sagt, dass die neue Sprache mehr Zukunft hat. Bei Cobol wurde schon lange gesagt, dass es keine Zukunft mehr hat, aber ich hab am Wochenende erst erfahren, dass eine mir bekannte Firma vier Programmierer einstellen würde. Gehaltsnennwert 80k auf Verhandlungsbasis. Gewünscht sind auch Kenntnisse über den .NET-Adapter für Cobol. Also so tot hört sich das nicht an und wird auch immer noch eingesetzt. Es wird lediglich von Programmieren boykottiert, da sich diese Sprache niemand mehr antun will.