.Net oder MFC?
-
Schneller und einfacher ist relativ. Wenn man 15 Jahre lang mit C++/MFC programmiert hat, dann ist C#/.NET ein totaler Neuanfang. Die Produktivität dürfte anfangs gegen 0 gehen.
-
mike2003 schrieb:
Hallo,
ich möchte eine Verwaltungssoftware für ein Hotel schreiben. Der Nutzer soll über die Zimmernummer sehen können, wann dieses Zimmer reserviert ist. Das klingt relativ einfach und habe auch schon eine Idee wie ich das Ganze umsetze.
Da ich jahrelange Erfahrung mit der MFC habe und mich auch mit DB's auskenne wollte ich eine dialogbasierte Anwendung schreiben die über die ADO-Schnittstelle mit einer DB wie MySQL oder einfacher Access verbunden wird. Da aber die MFC schon sehr veraltet ist und ich mich mehr oder weniger mit dem Net-Framework beschäftigen möchte, habe auch in dieser Richtung überlegt. Ok dort habe ich weniger Erfahrung aber da das Projekt nicht eilt habe ich Zeit um mich auch darin einzuarbeiten, was Aufgrund meiner Java-Kenntnisse nicht so schwer sein sollte.
Hallo,
Ich würde dir auch zu .NET/C# oder Java raten. MFC-Programme sind schlecht erweiterbar, wenn du es mit nicht-Mircosoft Technologien zu tun bekommst. Also, wenn Deine Software Zukunftssicher sein soll, dann nimm .NET oder Java, nicht C++ und MFC.
Hinweis: Kein Trollversuch oder Flamewar. Ich bin C++ Programmierer, habe schon vieles mit den MFC programmiert und mag C++ sehr gern
-
sri schrieb:
Schneller und einfacher ist relativ. Wenn man 15 Jahre lang mit C++/MFC programmiert hat, dann ist C#/.NET ein totaler Neuanfang. Die Produktivität dürfte anfangs gegen 0 gehen.
Wenn man 15 Jahre lang nur MFC programmiert und jegliche Innovationen verpennt hat, sollte man in der Tat wohl lieber dabei bleiben.
-
byto schrieb:
Wenn man 15 Jahre lang nur MFC programmiert und jegliche Innovationen verpennt hat, sollte man in der Tat wohl lieber dabei bleiben.
Was ist bei .NET innovativ? Dass die Anwendungen 10x länger brauchen, um zu starten und man sich für eine zeitnahe Anzeige eines Startbildschirms ein natives C++-Programm schreibt, welches anschließend die .NET-Anwendung startet? Oder dass man ohne P/Invoke aufgeschmissen ist? Auf solche "Innovationen" kann ich gut verzichten.
-
Ich finde deine Gründe gegen .NET nicht wirklich stichhaltig.
Mit MFC habe ich nie programmiert, aber es soll wxWidgets ja nicht unähnlich sein, also eenn es kein (zeitliches?) Problem für dich ist etwas neues zu lernen und sonst nichts gegen .NET spricht würde ich dir auch zu .NET raten(als Alternativen gäbe es Java oder andere C++ Bibliotheken. Für Windows Only finde ich .NET in dieser Hinsicht aber schon ziemlich gut) und auch wenn der Benutzer es selbst installieren sollte, kannst du den .NET Installer immer noch in deinen eigenen einbauen.Was ist bei .NET innovativ?
In Bezug auf GUI?
schonmal was von WPF gehört?
-
Ohne Zweifel .NET. Benutze es seit 2 Jahren und bin vor allem von den WinForms begeisert. Im Gegensatz zu dem MFC/wxWidgets Gefrickel macht das sogar richtig Spaß.
Dass MS voll auf .NET setzt und jeglichen MFC Support eingestellt hat, war für mich zwar kein echter Grund, aber irgendwie wollte ich dann doch nicht auf eine aussterbende Lib setzen.
-
sri schrieb:
byto schrieb:
Wenn man 15 Jahre lang nur MFC programmiert und jegliche Innovationen verpennt hat, sollte man in der Tat wohl lieber dabei bleiben.
Was ist bei .NET innovativ? Dass die Anwendungen 10x länger brauchen, um zu starten und man sich für eine zeitnahe Anzeige eines Startbildschirms ein natives C++-Programm schreibt, welches anschließend die .NET-Anwendung startet? Oder dass man ohne P/Invoke aufgeschmissen ist? Auf solche "Innovationen" kann ich gut verzichten.
Selten in einem Posting so viel Bullshit gelesen. Alleine der Quark mit P/Invoke zeigt, dass du keine Ahnung hast.
-
anmerker schrieb:
Dass MS voll auf .NET setzt und jeglichen MFC Support eingestellt hat, war für mich zwar kein echter Grund, aber irgendwie wollte ich dann doch nicht auf eine aussterbende Lib setzen.
Solche Gerüchte gewinnen auch durch ständige Wiederholungen nichts an Wahrheit. Mit dem SP1 für VS2008 gab es eine große Oberflächenbibliothek, u.a. auch zur Ribbon-Erstellung. Für VS2010 sind folgende Erweiterungen geplant:
The next release of MFC will provide encapsulations around a number of new Windows platform features. With this functionality you can easily build applications that integrate into features such as desktop search, application restart and recovery functionality, leverage the new Windows UI metaphors such as Live Icons and Rich Preview. These features represent one of the most significant updates to MFC in years.
Mehr: http://channel9.msdn.com/pdc2008/PC26/
Von Einstellung des Supports und einer austerbenden Lib kann ich da nichts herauslesen.
autsch22 schrieb:
Selten in einem Posting so viel Bullshit gelesen. Alleine der Quark mit P/Invoke zeigt, dass du keine Ahnung hast.
Nun, die Sache mit dem Startbildschirm ist keine Erfindung. Das wird bei einer mir bekannten größeren Anwendung wirklich so gemacht. Und jeder zweite C#-Artikel, den ich auf CodeProject lese, kommt nicht ohne P/Invoke aus. Dann kann ich auch gleich nativen Code schreiben.
Aktive Programmiererfahrung mit .NET habe ich wirklich keine. Aber das, was ich bisher gesehen habe, kann mich nicht überzeugen, eine größere funktionierende C++/MFC-Codebasis einfach so wegzuwerfen und quasi wieder bei Null anzufangen. Das ist für mich keine Innovation, das wäre Selbstmord.
-
Von Einstellung des Supports und einer austerbenden Lib kann ich da nichts herauslesen.
Alleine, dass Microsoft (afaik) ursprünglich vor hatte die WinAPI und MFC komplett durch .NET zu ersetzen zeigt doch, dass es das loswerden möchte. Dass dies so bald nicht geschieht liegt an der Benutzung der beiden und an den Projekten die damit noch gewartet werden und an was weiß ich alles, aber nicht daran, dass Microsoft die MFC am leben erhalten möchte, weil sie gut sei.
r das, was ich bisher gesehen habe, kann mich nicht überzeugen, eine größere funktionierende C++/MFC-Codebasis einfach so wegzuwerfen und quasi wieder bei Null anzufangen
Und sowas ist vermutlich der Grund warum es MFC noch gibt? Da sag ich auch nichts gegen, die Frage ist ob für dieses Projekt eine größere Codebasis vorhanden ist.
Aktive Programmiererfahrung mit .NET habe ich wirklich keine
Ja, das merkt man
P/Invoke hab ich in der Zeit in der ich mit C# programmiert hab(bis es zur Anforderung wurde auch für Linux zu entwickeln) kein einziges mal verwendet, genau so wenig C++/CLI. Die .NET Umgebung hat immer ausgereicht.
-
JustAnotherNoob schrieb:
Alleine, dass Microsoft (afaik) ursprünglich vor hatte die WinAPI und MFC komplett durch .NET zu ersetzen zeigt doch, dass es das loswerden möchte. Dass dies so bald nicht geschieht liegt an der Benutzung der beiden und an den Projekten die damit noch gewartet werden und an was weiß ich alles, aber nicht daran, dass Microsoft die MFC am leben erhalten möchte, weil sie gut sei.
Microsoft hatte es anfangs sicher vor, ist damit aber grandios gescheitert. Es wurde einfach nicht bedacht, dass viele Entwickler (innerhalb und außerhalb von MS) gar nicht gewillt waren, ihre bisherigen Investitionen aufzugeben. Mittlerweile hat MS erkannt, dass C#/.NET nicht die alleinige Zukunft ist.
Ob die MFC gut oder schlecht ist, liegt sicher im Auge des Betrachters. Fakt ist, dass sie eine lange Geschichte hat und immer (mit kleineren Einschränkungen) abwärtskompatibel geblieben ist. Natürlich entspricht sie nicht den Erwartungen, die man heute an eine moderne C++-Bibliothek hat. Dafür müsste man sie wohl von Grund auf wieder neu schreiben. Mir war/ist sie jedenfalls ein großer Helfer und ich möchte sie nicht missen.
JustAnotherNoob schrieb:
P/Invoke hab ich in der Zeit in der ich mit C# programmiert hab(bis es zur Anforderung wurde auch für Linux zu entwickeln) kein einziges mal verwendet, genau so wenig C++/CLI. Die .NET Umgebung hat immer ausgereicht.
Ich habe viel mit der Shell zu tun. Und wenn man mal vom kürzlich veröffentlichten Shell API-Pack absieht, geht es da nicht viel ohne Aufrufe der nativen Funktionen bzw. COM.