Click here to Skip to main content
Click here to Skip to main content

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

By , 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.

License

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.

Comments and Discussions

 
GeneralReason for my vote of 4 The concept warrants a 5, but I thin... PinmemberBlake Miller13-Sep-10 9:41 
GeneralReason for my vote of 4 Interesting discussion of why MFC is... PinmemberAescleal25-Aug-10 8:44 
GeneralLeave model out of CDocument AND CView. PinmemberBlake Miller13-Sep-10 9:39 
I agree with the analysis presented here. If you embed the model in the CDocument, then it makes it much harder to expose your model data to a Windows Service, or a stand alone COM object or to provide the model as an exmaple of your data to another source (Even another CDocument!). The CDocument and CView are too tightly-coupled to a Windows User-Interface application.
 
I typically make the CView do all the 'user interaction' work, and the CDocument 'manipulate' the model data in response to one or more CView types. It is not frequently encountered, but just as you can attach multiple document types to the multi-doc template (so you get a choice of which document type to create when you select File |New from the menu), you can attach multiple CView types to a document. Then when you do New Window, you get a choice of which Window Type to see.
 
So, the CView is not only a 'view' into the data, but also a means for the user to manipulate it. The CDocument acts as an interface between the CViews to the model data. I typically place all enforcement of data integrity within the POCO class itself.
 
Besides just as a pass through, the CDocument might have 'meta' operations it performs upon the data on behalf of the CView. Also, since one more more views can be open on a document at a time, the document must notify the views when data has changed.
 
For a simplistic and perhaps somewhat lame example, suppose you have a 2X2 matrix of data. The POCO class can provide a function to shift a specified area of the matrix left or right one element at a time. The CDocument can wrap that by looping the shifting, on behalf of a CView which provides the area (user selected via GUI) and the loop count. The CView does NOT do the looping, it merely tells the CDocument the sleection and loop count. The CDocument iteratively calls the POCO class' shifter one or more times.

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

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

| Advertise | Privacy | Mobile
Web03 | 2.8.140415.2 | Last Updated 19 Aug 2010
Article Copyright 2010 by Issam Lahlali
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid