C++ MFC vs .NET?

Question

My colleagues are using Visual Studio 2002 and uses the C++ MFC. I am developing in C #.

It has not been any problems before, but now questioning our customers if we re

Answer 1

MFC and .NET are at nearly opposite extremes, each thoroughly crappy in its own way.

Using MFC is roughly on the order of living in the decaying wreck of a WW II surplus building. There aren't any signs to warn about dangerous areas, and it's probably not immediately apparent where to find running water, electricity, or a toilet that works -- even though all of them are there, if you know how to find them. Like any decaying building, there are plenty of holes in the walls and such, so you can leave anytime you want for as long as you want. Likewise, dragging in things from the outside world is pretty easy, though it's pretty much up to you to do the "dragging" to get it there.

Using .NET is like living on the set of The Truman Show. It fits one person's idea of what real life should be like. Within its boundaries, life can seem Utopian. In the end, however, it's little more than a pleasantly accoutered prison cell, and none of what it portrays as life is quite real. All your interaction with the outside world is subject to the whim of a director whose aims are mostly to improve his own ratings; your welfare is considered only to the extent that it affects him.

Unlike most prisons, .NET does have a well marked escape route (labeled "P/Invoke"). Like the escape route from any good prison, however, it's a mile-long sewage pipe. Most residents are aware of its existence, but nearly the only who go there are teenagers proving their manliness. The few who put it to real use do so only in dire necessity. Those of us who found it necessary once too often have realized it's better to just stay outside and not go back in.

Edit: Since some people want circles and arrows and a paragraph on the back of each one to be used as evidence in court: MFC's strength and weakness is that it's mostly a fairly thin wrapper around the API. That's a weakness because there are a fair number of holes in its coverage, and because it does relatively little to "smooth over" the places that the API itself doesn't fit together particularly well. For example, if something is implemented using COM, that will usually show up directly in your code that uses it. It's a strength, because it's fairly easy to extend MFC to handle areas it doesn't by default, as well as to simply bypass it and work directly with the API when you need to do so. It's also been updated relatively infrequently, so while it can currently produce reasonably "modern" looking applications, that hasn't always been the case. Given its history, it would be hard to predict that it'll continue to be the case.

.NET's strength and weakness is that it's a much "thicker" wrapper around the API. It does considerably more to "smooth over" differences in the API, so (for example) parts that are implemented in COM don't look/act noticeably different from parts that are implemented as straight C function calls. From inside .NET, the differences disappear. .NET is (currently) Microsoft's favored technology, so it's updated much more regularly, and does a much better job of ensuring that your UI follows the latest guidelines. My guess is that it's much more likely than MFC to continue doing so for some time.

The weakness of .NET is that it's much more difficult to bypass or extend. Basically, your only route to the outside world is through P/Invoke. Even for small excursions, it's ugly and painful. Trying to use it very often or for anything approaching a major extension is an exercise in masochism.

If (nearly) everything you write can fit within what .NET supports, it's the clear choice. It's much cleaner and smoother as long as you stay inside its boundaries.

If you write code that fairly frequently needs to go outside the bounds supported by the framework, MFC will probably work much better for you. With .NET, the .NET model applies to your whole program. With MFC, it's relatively easy to write programs that use MFC for their UI, and do things however they want for anything else that MFC doesn't support.