Where's the model for MFC Doc/View Design?

MFC is a good library that wraps Windows API, and it's also a framework so it provides a structure for your application and influent the design.

We have to be careful when using frameworks, because it impact also the design, and accepting the structure imposed by a specific framework without understanding its impact could be dangerous.

Let's take a look into Doc/View architecture proposed by MFC and discuss how MVC pattern could be implemented.

Did CDocument/CView implements MVC pattern?

Doc/View architecture as described by many articles is implementing MVC pattern, but where's the Model, the controller and the view?

Here's a description from msdn:

"The Document-View variant recognizes all three roles of Model-View-Controller but merges the controller into the view. The document corresponds to the model role in MVC. This variant is present in many existing GUI platforms. An excellent example of Document-View is the Microsoft Foundation Class Library (MFC) in the Microsoft Visual C++ environment. The tradeoff of using this variant is that the view and the controller are more tightly coupled."

So the CDocument is the model and CView merge the view and controller.



But actually the CDocument is not representing only the model , and to proof it let's discover some CDocument design and methods:

CDocument derives from CCmdTarget to receive events and commands and contains the following methods : AddView, GetFirstViewPosition,GetNextView,UpdateAllViews.

So this class treats events,refresh and manage views, so it have some controller responsability.

Why CDocument is not the good candidate to be the model?

As described below the CDocument contains controller logic, and considering it also as model impact a lot the cohesion of classes, each class must have a specific responsibility; it makes the design more flexible.

The model must be independent of any framework used, if it can be a POCO classes it will be wonderful, the question is why coupling the model with a specific framework?
high coupling makes the design more rigid, and any evolution or changes will be very difficult, for example if some client ask to provides also webservices, and if our model is highly coupled with CDocument , this evolution will cost a lot, on the other side if it's independent to CDocument it can be developed more easily.

What's the conclusion of this story?

• High cohesion and low coupling are two powerful concepts that assist your design, but their benefits are more visible only if evolutions or changes are needed.
• Be careful when using external frameworks, and not understanding the design provided by the framework could impact a lot the design quality of your application.