MFC veraltet?
-
asc schrieb:
Bulli schrieb:
Das die MFC von MS noch ernsthaft weiter unterstützt wird, sieht man schon alleine daran, das die Ribbons für die MFC rausgekommen sind.
Sie wird aber kaum mehr von MS-Seite gepflegt, und auch die neuen Controls sind weitgehend (wenn nicht gar gänzlich) zugekauft. Ich suche aber jetzt nicht den Hersteller heraus, der diese Controls entwickelt hat. Was tatsächlich neu hinzu kam sind wohl einige Konvertierungsfunktionen (kann aber sein das dies nur im Bereich C++CLI war, bin mir hier nicht ganz sicher).
Völlig irrelevant ob MS irgendwas zukauft! Die Stdlib ist auch von Dinkumware zugekauft. Und?
MS hatte auch mal darüber nachgedacht ein Refactoring Plug-in für C# einzukaufen. Hem... C# wird somit wohl nicht mehr von MS unterstützt?Sie haben den MFC-Anwendern die Ribbons nachgeliefert, damit die Leute weiter MFC benutzen können. So sehe ich das!
-
asc schrieb:
[
Bestehende MFC-Programme sollte man imho langfristig portierenBegruendung?
Eine Portierung kostet sehr sehr viel Geld - warum sollte man das zahlen, welchen Vorteil haette man davon?
-
MFC war und ist nur eine drübergestülpte Programmieroberfläche auf die komplexe WinApi. Irgendwo klemmt so etwas immer - und dann ist es besser gleich die WinApi zu benutzen. Wer mit MFC klarkommt, soll dabei bleiben. Ich mag diese oder andere Programmieroberflächen nicht.
-
berniebutt schrieb:
und dann ist es besser gleich die WinApi zu benutzen
Interessant. Warum?
-
berniebutt schrieb:
MFC war und ist nur eine drübergestülpte Programmieroberfläche auf die komplexe WinApi.
Das ist für mich der Grund MFC zu verwenden.
-
Shade Of Mine schrieb:
asc schrieb:
Bestehende MFC-Programme sollte man imho langfristig portieren
Begruendung?
Eine Portierung kostet sehr sehr viel Geld - warum sollte man das zahlen, welchen Vorteil haette man davon?
Wenn ein Programm noch lange in Einsatz sein soll, sollte man sich von Zeit zu Zeit mal Gedanken über die Entwicklung machen. Es heißt ja nicht das man es zwangsläufig portiert, aber man sollte möglichst viel portierbar halten (Sprich: möglichst saubere Programmierung und Kapselung), um nicht später einmal das nachsehen zu haben. Was ist, wenn eine Plattform doch einmal eingestellt wird, oder nach einer angekündigten Zeit ausläuft (ersteres halte ich weder bei der WinApi noch MFC für realistisch, wohl aber zweites durchaus für denkbar).
Ich habe schon die ein oder andere Bibliothek sterben sehen, und man sollte zumindest vermeiden das langfristige Projekte nicht wenigstens eine gewisse Portierung zulassen. Es ist bereits jetzt eine Tendenz dafür zu sehen das nach und nach .Net über die Windows API hinaus weiterentwickelt wird, und ich glaube kaum das die Experimente wie Singularity & Co gänzlich ohne Hintergrund entstanden sind.
Ich glaube kaum das WinAPI/MFC die nächsten 3 Windowsversionen stirbt, aber länger planen will ich persönlich erst, wenn MS eindeutig wieder von .Net Abstand nimmt, oder man die Funktionalitäten wie z.B. bei der WPF in die WindowsAPI zurückfließen lässt.
cu André
-
asc schrieb:
Es ist bereits jetzt eine Tendenz dafür zu sehen das nach und nach .Net über die Windows API hinaus weiterentwickelt wird, und ich glaube kaum das die Experimente wie Singularity & Co gänzlich ohne Hintergrund entstanden sind.
Aber du machst dir doch hoffentlich nicht die Hoffnung, daß deine WinForms-Projekte unter einem hypothetisch marktfähigen Singularity 3.1 irgendwie lauffähig sein werden?
-
audacia schrieb:
asc schrieb:
Es ist bereits jetzt eine Tendenz dafür zu sehen das nach und nach .Net über die Windows API hinaus weiterentwickelt wird, und ich glaube kaum das die Experimente wie Singularity & Co gänzlich ohne Hintergrund entstanden sind.
Aber du machst dir doch hoffentlich nicht die Hoffnung, daß deine WinForms-Projekte unter einem hypothetisch marktfähigen Singularity 3.1 irgendwie lauffähig sein werden?
Nein, wie überall muss man auch hier von Zeit zu Zeit das Projekt etwas aktualisieren. Und auch dort gilt für mich: Portierungen niemals ausschließen, und den Code versuchen verständlich zu halten. Davon abgesehen das ich bei neuen .Net Projekten auch schon wieder eher zu WPF greifen würde.
Nichts für ungut, aber wer zweimal in 10 Jahren das mehr oder weniger Einstellen von zwei Programmierumgebung (in einen Fall inzwischen wiederbelebt) erlebt hat, und weiß wie träge Entscheider beim Wechsel sind, riskiert lieber das man regelmäßig den Entscheidern mitteilt ab und zu zu aktualisieren. Selbst wenn dies ein paar unfreundliche Worte nach sich zieht. Ich bin erst kürzlich von einer Firma weg, die sich an einem seit 8 Jahren eingestellten Framework festklammert.
Das eine Umstellung Kosten verursacht, und langwierig ist, ohne Frage. Aber gerade daher würde ich immer von den Grundsatz ausgehen: Lieber von Zeit zu Zeit Codepflege betreiben, nicht in Techniken setzen die nur am Rande gepflegt werden (Bei der MFC habe ich inzwischen Bauchschmerzen was das angeht) - und sei es zumindest bei neuen Projekten.
cu André
-
asc schrieb:
Shade Of Mine schrieb:
asc schrieb:
Bestehende MFC-Programme sollte man imho langfristig portieren
Begruendung?
Eine Portierung kostet sehr sehr viel Geld - warum sollte man das zahlen, welchen Vorteil haette man davon?
Wenn ein Programm noch lange in Einsatz sein soll, sollte man sich von Zeit zu Zeit mal Gedanken über die Entwicklung machen. Es heißt ja nicht das man es zwangsläufig portiert, aber man sollte möglichst viel portierbar halten (Sprich: möglichst saubere Programmierung und Kapselung), um nicht später einmal das nachsehen zu haben. Was ist, wenn eine Plattform doch einmal eingestellt wird, oder nach einer angekündigten Zeit ausläuft (ersteres halte ich weder bei der WinApi noch MFC für realistisch, wohl aber zweites durchaus für denkbar).
Ich habe schon die ein oder andere Bibliothek sterben sehen, und man sollte zumindest vermeiden das langfristige Projekte nicht wenigstens eine gewisse Portierung zulassen. Es ist bereits jetzt eine Tendenz dafür zu sehen das nach und nach .Net über die Windows API hinaus weiterentwickelt wird, und ich glaube kaum das die Experimente wie Singularity & Co gänzlich ohne Hintergrund entstanden sind.
Ich glaube kaum das WinAPI/MFC die nächsten 3 Windowsversionen stirbt, aber länger planen will ich persönlich erst, wenn MS eindeutig wieder von .Net Abstand nimmt, oder man die Funktionalitäten wie z.B. bei der WPF in die WindowsAPI zurückfließen lässt.
cu André
Das ist doch völlig unrealistisch, wenn du jede Bibliothek erst einmal kapselst, da hast du ja arbeit ohne Ende und meist kann man die Bibliothek dann doch nicht so ohne Probleme auswechseln, weil man das Interface zu nahe an der verwendeten Bibliothek entwickelt hat.
-
Man soll nicht jede Bibliothek kapseln, sonder die Anwendungslogik so unabhänig wie möglich von jeder API entwickeln.
-
Realistiker schrieb:
Das ist doch völlig unrealistisch, wenn du jede Bibliothek erst einmal kapselst, da hast du ja arbeit ohne Ende und meist kann man die Bibliothek dann doch nicht so ohne Probleme auswechseln, weil man das Interface zu nahe an der verwendeten Bibliothek entwickelt hat.
1. Geht es nicht zwangsläufig um das kapseln von Bibliotheken, auch wenn ich dies teilweise machen würde (Klar, die UI ist meist ziemlich Frameworkabhängig, und auch DB-Zugriffe, die Logik dazwischen würde ich aber tatsächlich versuchen weitgehend frei von speziellen Bibliotheken zu halten, oder den Code wenigstens sauber strukturieren.
2. Code in dem man (unabhängig vom Framework) saubere Trennungen vornimmt (z.B. n-Tier oder ähnliche Konzepte), lässt sich auch eher portieren (Portierung heißt ja nicht zwangsweise das man von heute auf morgen alles umstellt, sondern das man ggf. mit kleinen Bereichen anfangen kann).
3. Code der regelmäßig gewartet wird (Refactoring ist z.B. ein Thema), ist verständlicher, und lässt sich leichter zumindest bezüglich der Logik übernehmen (von einer besseren Wartung ganz zu schweigen, aber da sind ja gerade Entscheider häufig blind: Wozu Refactoring, das bringt doch keine neue Funktionalität).
Es geht wie gesagt nicht um eine zwangsweise Umstellung, sondern nur das man die Wege offen hält um es durchführen zu können, ohne wirklich alles Neuschreiben zu müssen. Und es geht mir darum, das ich bei neuen Projekten lieber zweimal darüber nachdenken würde ob ein Framework xyz noch gewartet wird oder nicht.
cu André
@Zeus: Danke, schön kurz gefasst
-
Walli schrieb:
Sowas lese ich immer nur ueberall, aber ich habe selbst noch keine Firma gesehen, die das so macht. Selbst bei Neuentwicklungen habe ich nicht gehoert, dass jemand von MFC weg ist und auf .NET gesetzt hat.
Ich kenne einige Firmen die .NET einsetzen, für die verschiedensten Dinge. Du brauchst auch bloss mal gucken wieviele C# Programmierer gesucht werden.
Dass eine Firma von MFC weggeht is wieder eine andere Sache. Das passiert oft nicht, weil die Firmen die schon länger MFC verwenden eben nen Haufen C++ Programmierer haben, die sich mit der MFC bereits auskennen, u.U. viel eigenen Library- bzw. Framework-Code etc. Wenn man nicht neue Leute einstellt (was meist bedeutet: andere dafür entlassen) kann es recht lange dauern bis eine Firma von etwas wegwechselt - egal wie mies/veraltet/umständlich/... es ist.
Wenn du dir aber jüngere Firmen bzw. neue Projekte (mit neuen Teams) ansiehst wirst du vermutlich viel mehr .NET als MFC finden. Mittlerweile hoffentlich fast ausschliesslich C#, früher auch noch viel Visual Basic .NET (*schauder*).
-
hustbaer schrieb:
Dass eine Firma von MFC weggeht is wieder eine andere Sache. Das passiert oft nicht, weil die Firmen die schon länger MFC verwenden eben nen Haufen C++ Programmierer haben...
ich kenne da so'nen laden, absolute ms-fanatiker. früher haben sie nur vc (mit mfc) und vb verwendet. seit ca. 3...4 jahren nehmen sie für neue projekte nur noch .NET (c# und vb). an dem alten zeug basteln sie manchmal weiter, aber es wird nicht nach .NET portiert, das wäre viel zu aufwändig. ach ja: die jungs haben irgendwelche sonderverträge mit ms. ich weiss daher nicht, bis zu welchem grad sie von m$ gezwungen werden, das .NET-zeugs einzusetzen.
-
Na, ihr arbeitet wohl alle bei Start-up-Firmen, wie?
Bei uns haben wir produktiven Code in COBOL, der seit 30 Jahren läuft und weiter entwickelt wird (ja, sogar damit neue Projekte angefangen werden!). Und nein, er wird nicht nach Java oder C# portiert. Wenn jemand mit dieser Idee ankommen würde, würde man ihn wohl in eine Zwangsjacke stecken! Es ist total unsinnig alten funktionierenden Code zu portieren! Um so länger er existiert, um so unwahrscheinlicher wird ein Port!Klar, wenn ich gestern angefangen habe ein Projekt in Sprache X anzufangen, und ich stelle fest, das es mit der neuen Sprache Y besser gehen würde, kann ich noch umschwenken. Aber ich bezweifel mal, das die meisten MFC-Projekte gestern angefangen wurden...
-
Shade Of Mine schrieb:
Interessant. Warum?
Weil ich dann sehe, was passiert und nicht mühsam in den Beschreibungen fremder Klassenbibliotheken herumwühlen muss. Erscheint mir einfacher!
-
Bulli schrieb:
Na, ihr arbeitet wohl alle bei Start-up-Firmen, wie?
Gut, 30 Jahre kann ich nicht aufbieten, die Projekte laufen bislang nur im Bereich von 10+ Jahren. Nur laufen diese Projekte auf aktuellen Plattformen, und es haben sich im Laufe der Zeiten immer wieder Inkompatibilitäten mit den jeweils aktuellen OS gezeigt.
Sei es nun das bestimmte API-Aufrufe sich inzwischen geändert haben (weil sich das Rechtesystem geändert hat), sei es das Teile des Frameworks auf 16-Bit Funktionen basiert hatten, oder das auf einmal ein Klick innerhalb eines Controls auf einmal einen nervigen Ton auslöst.
Bulli schrieb:
Es ist total unsinnig alten funktionierenden Code zu portieren!
Entweder hast du eine homogene Umgebung die sich auch kaum ändert, oder aber eure Projekte haben das Glück nicht auf Inkompatibilitäten zu stoßen. Vielleicht wird euer Framework ja noch aktualisiert, wenn dies nicht der Fall ist, und davon kein Code sondern nur binäre Bibliotheken existieren, viel Spaß.
Bulli schrieb:
Um so länger er existiert, um so unwahrscheinlicher wird ein Port!
Gerade wenn der Code nicht von zeit zu Zeit etwas aktualisiert und überarbeitet wird, und ebenso wird mit diesen Bedingungen auch die Wartbarkeit immer aufwendiger.
Bulli schrieb:
Aber ich bezweifel mal, das die meisten MFC-Projekte gestern angefangen wurden...
Das Thema begann auch mit der Frage aktuell damit zu beginnen. Und Code prinzipiell portabel zu halten ist sicher kein Fehler, da es meist auch die Wartbarkeit erhält.
cu André
-
berniebutt schrieb:
Shade Of Mine schrieb:
Interessant. Warum?
Weil ich dann sehe, was passiert und nicht mühsam in den Beschreibungen fremder Klassenbibliotheken herumwühlen muss. Erscheint mir einfacher!
Verstehe ich nicht.
Ob ich jetzt SetEvent(evt) oder evt.SetEvent() mache - wo ist der große Unterschied?MFC ist ja eben so käse gekapselt dass es eigentlich nur eine mehr oder weniger objekt orientierte version der winapi ist.
ich würde die argumentation bei Qt, gtk, etc. verstehen - diese abstrahieren ja wirklich, aber die MFC bietet ja keine abstraktionsschicht. das ist zB mein kritik punkt - es ist einfach nur die winapi 1:1 nur eben statt foo(bar) schreibt man bar.foo() und man hat als bonus grafische editoren für die fenster
-
Shade Of Mine schrieb:
berniebutt schrieb:
Shade Of Mine schrieb:
Interessant. Warum?
Weil ich dann sehe, was passiert und nicht mühsam in den Beschreibungen fremder Klassenbibliotheken herumwühlen muss. Erscheint mir einfacher!
Verstehe ich nicht.
Ob ich jetzt SetEvent(evt) oder evt.SetEvent() mache - wo ist der große Unterschied?MFC ist ja eben so käse gekapselt dass es eigentlich nur eine mehr oder weniger objekt orientierte version der winapi ist.
ich würde die argumentation bei Qt, gtk, etc. verstehen - diese abstrahieren ja wirklich, aber die MFC bietet ja keine abstraktionsschicht. das ist zB mein kritik punkt - es ist einfach nur die winapi 1:1 nur eben statt foo(bar) schreibt man bar.foo() und man hat als bonus grafische editoren für die fenster
Seit wann hat man einen Editor für Fenster bei der MFC? Da kann ich doch nur Dialoge und ein paar vordefinierte Sachen fürs Hauptfenster einstellen. Wenn man sich dagegen den QT Designer anschaut...
-
Hö??? schrieb:
Seit wann hat man einen Editor für Fenster bei der MFC? Da kann ich doch nur Dialoge und ein paar vordefinierte Sachen fürs Hauptfenster einstellen. Wenn man sich dagegen den QT Designer anschaut...
Dialoge sind auch Fenster
-
Shade Of Mine schrieb:
MFC ist ja eben so käse gekapselt dass es eigentlich nur eine mehr oder weniger objekt orientierte version der winapi ist.
Du hast es aber auch mit dem Käse
Shade Of Mine schrieb:
und man hat als bonus grafische editoren für die fenster
Ressourceneditoren kannst du ebensogut für Plain-WinAPI-Anwendungen benutzen.
Aber nichtsdestotrotz existieren die MFC ja nicht ganz grundlos; es ist nicht so, daß sie nicht zur Codereduktion beitragen könnten. Aber es gibt, wie nun oft genug hervorgehoben wurde, genügend bessere Abstraktionen des Windows-API.
