MFC veraltet?

[nep]

Ich schon, und zwar fast überall bei Firmen die zuvor MFC & Co verwendet haben.

[~fricky]

Bulli schrieb:

Wenn es um "veraltet" geht, dann ist damit immer gemeint, das es kein schönes C++ ist.

das spielt überhaupt keine rolle. hauptsache es funzt. und das tut MFC ja.

[Unix-Tom]

Firmen gibt es viele die auf Net setzen.
Man darf nicht immer nur von Anwendungen ausgehen die vielleicht die Firma selbst braucht.
Ich spreche hier von Unternehmen.
z.B. Moss 2007 und NET.
MS Dynamics 2009
etc.

[asc]

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).

Bestehende MFC-Programme sollte man imho langfristig portieren (nicht von heute auf morgen, aber vielleicht schon einmal so sauber überarbeiten das eine Portierung leichter möglich ist), bei neuen Projekten, gerade wenn sie langfristig geplant sind, würde ich von der MFC aber abraten.

Bulli schrieb:

Für .NET ist das glaube ich noch nicht passiert? Und wenn doch, dann erst nach den den MFC-Ribbons.

Die Ribbonerweiterung für .Net kam soviel ich weiß vor dem 2008er VS raus, kann mich aber auch irren. Und das sie die MFC überhaupt noch marginal pflegen, so liegt es eher daran das noch einige Firmen an der MFC festhalten. Von MS wird aber schon längere Zeit auf andere Alternativen verwiesen.

Bulli schrieb:

Wenn es um "veraltet" geht, dann ist damit immer gemeint, das es kein schönes C++ ist.

Und das die Unterstützung seitens MS nicht mehr wirklich gut ist. Kleine Präsente hier und da haben nichts mit einer guten Unterstützung gemein.

cu André

[Cpp_Junky]

asc schrieb:

...

Bestehende MFC-Programme sollte man imho langfristig portieren (nicht von heute auf morgen, aber vielleicht schon einmal so sauber überarbeiten das eine Portierung leichter möglich ist), ...

Wie soll denn das funktionieren? Also mal abgesehen von der Variante AllesNeuIn.Net(tm) ?

[Gast]

Hallo

dllimport

chrische

[Roflcopter]

Portieren einer MFC Anwendung ist doch unmöglich, es sei denn man hätte das MVC-Pattern benutzt, aber welcher MFC Entwickler tut das schon? Da wird schon das Doc/View von der MFC benutzt und schon steckt man so tief in der MFC drin, dass es keinen Ausweg mehr gibt.

[Bulli]

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!

[Shade Of Mine]

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?

[berniebutt]

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.

[Shade Of Mine]

berniebutt schrieb:

und dann ist es besser gleich die WinApi zu benutzen

Interessant. Warum?

[Fusel.Factor]

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.

[asc]

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é

[audacia]

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?

[asc]

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é

[Realistiker]

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.

[Zeus]

Man soll nicht jede Bibliothek kapseln, sonder die Anwendungslogik so unabhänig wie möglich von jeder API entwickeln.

[asc]

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

[hustbaer]

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*).

[~fricky]

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.