Click here to Skip to main content
13,551,695 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


3 bookmarked
Posted 19 Aug 2010
Licenced CPOL

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

, 19 Aug 2010
Rate this:
Please Sign up or sign in to vote.

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.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Issam Lahlali
Software Developer (Senior)
United States United States
CppDepend lead developer.

You may also be interested in...


Comments and Discussions

GeneralReason for my vote of 4 The concept warrants a 5, but I thin... Pin
Blake Miller13-Sep-10 9:41
memberBlake Miller13-Sep-10 9:41 
GeneralReason for my vote of 4 Interesting discussion of why MFC is... Pin
Aescleal25-Aug-10 8:44
memberAescleal25-Aug-10 8:44 
GeneralLeave model out of CDocument AND CView. Pin
Blake Miller13-Sep-10 9:39
memberBlake Miller13-Sep-10 9:39 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01-2016 | 2.8.180515.1 | Last Updated 19 Aug 2010
Article Copyright 2010 by Issam Lahlali
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid