I have a phone-book program written in C++, that uses the MVC model, now what I want is to replace the View component, that's basically the console window, with an MFC. How would I do that?
Following is a schematic representation of MVC. View component is lossely coupled from the Model and the Controller and that is the whole point behind MVC design pattern. Without changing the external interfaces of View, you should be easily able to replace internal implementation by MFC. And that is what you should do.
The question is very broad to answer anything more in detail, If you can post a sample code then probably we can help you better.
Related
I want to develop a MFC application in VS2010. I hope to separate GUI from the logic, so that modifying GUI can become much easier. But I don't know how to design the classes to implement this function. Which design pattern should I use? Does MFC have any special way to deal with the problem?
Moreover, I am not familiar with design patterns. So I hope someone can give me samples or detailed articles explaining this. (Also I prefer a less complicated pattern! ^^)
Thank you very much!
The MFC already provide such a separation in their SDI/MDI based templates. For example, you have a CWinApp instance and a CMainFrame for the program itself. For each file in MDI apps you have a CDocument and a CView class.
Note:
The MFC don't use the classic MVC separation, they combine the view and controller into a single UI part.
The MFC are not strict about this, you can also put a button handler into the application/document, not only into the frame/view.
You don't fully separate the model from the MFC, it is still built on that. If you want to achieve this separation, you have to do additional work, but then you have a module that you can test completely separately. This allows you to use test-driven development, which is more difficult when embedded into a GUI.
May be it will be helpful http://martinfowler.com/eaaDev/uiArchs.html . Also try to find MVC (model/view/controller) pattern.
I have been learning PHP MVC pattern and it is pretty cool. have almost finished app and I can see how mess you can make a code without good design.
Now can MCV be applied to C++ apps? Where does Plugin manager/Plugins go if that is even possible?In model or controller?
Thanks!
EDIT:
I mean C++ with GUI toolkit like QT/Wxwidgets/GTK+
Also Please help me on how to implement in C++. I have learned how to do it in PHP but as you know the two languages are somehow different!
EDIT2
http://forums.wxwidgets.org/viewtopic.php?f=1&t=30983
how do you actually implement it in C++
make classes in charge of rendering know nothing about application details. Call them SomethingView classes to make this point clear
make your domain objects not know anything about visualization or user interaction. You don't need to call them Model, but you could
create a set of classes in charge of running the role of Controllers: wire somehow dependencies to view and model classes via dependency injection if possible. example: CppInject. In any case, controller classes can know both about model and view classes, so the important part is this: all the coupling between view and model objects is isolated to the controllers.
Also, this implies, that all imperative-style programming should be confined to the controller classes as well: view and model should be declarative-style. That means, they should offer services related to its role, but avoid direct interaction with other objects as side-effects
It is not true you need to implement communication between controllers and the other components with event-style system, although such system is definitely helpful, but certainly not required
surprise! the above applies to any language or framework, except of course languages that somehow already force MVC down your throat from the start, i.e: ruby on rails
MVC is a design pattern not a language specific construct, So yes you can apply it to C++ app as well.
MVC can and should be applied in any language so your User Interface is loosely coupled with the backend & either can be changed with minimum impact on each other.
The MVC pattern provides a clean separation of objects into:
Models for maintaining data,
Views for displaying all or a portion of the data, and
Controllers for handling events that affect the model or view(s).
Yes, MVC can be applied in C++. For example, the MFC framework uses Document/View architecture which is essentially an MVC.
A design pattern isn't a library or class. It's a pattern. So you don't have a generic MVC library for C++.
Use Tree frogs Framework. TreeFrog Framework is a high-speed and full-stack C++ framework for developing Web applications.
MVC is an architectural design pattern (i.e. a way of building software) commonly associated with web applications, but it is applicable in general to any software project in any language. You have to make a little abstraction effort on your project, and identify which piece of software belongs to each part (i.e. a GUI is probably part of View, etc.).
Note that this type of pattern is mainly aimed to separate developement, so that any part of the project can be developed regardless of the others. This can be annoying for a small standalone application, but useful and rewarding on bigger projects.
Personally, I use boost state machines for the logical and boost signals to connect things together.
I wrote a little example that you can analyze here:
https://github.com/edubois/mvp-player
Can somebody point me to a good tutorial or sample project where MVP pattern has been implemented using Qt C++. I'm new to Qt as I come from VB.NET background. MVP is pretty common in VB.NET. Doing a Google search was not so fruitful either. Please somebody show me some real world example. Like in VB.NET we create complex model with IList of some base model. All these things are important. And what relevant data structures should be used where we used the Collection class for example.
To learn MVP, I suggest reading Michael Feather's article "The Humble Dialog Box":
webarchive link
(This is one specific form of MVP, there are other variants possible.)
The examples in that article are made with C++. There are not made with Qt, but more or less independent of the GUI framework. MVP is about the separation of your code into a framework dependent part and a framework-independent part, which can be learned by using almost any GUI framework.
how are the classses in MFC match the model-view-control pattern ?
the model is suppose to handle the Business Logic , the control suppose to be some kind of mediator and the view suppose to be the gui ?
what class in MFC represent each one ? cause it seems pretty different to me as i read more about mfc. (seems like CView represent the control, CfrmWnd the view , and CDocumnet the data- though i'm not sure if by data they mean BL)
clarifications ?
MFC is a Document/View architecture, not a full-blown MVC. Reference MFC Library Reference
Document/View Architecture.
In short in MFC the CDocument is the Model, and the CView classes combine the View and Controller aspects.
By "BL" in your question do you mean "business logic"? And in this case the CDocument does not mean business logic, but the actual data underlying your app.
MFC does not implement the MVC pattern. However, there are ways to integrate MVC with MFC.
MVC is to desktop widget libraries like the ISO OSI model is to the internet protocols. It just does not fit because it is too rigid.
I don't think a single pattern exists that describes MFC (or desktop GUI programming in general) well. Maybe the hierarchical Model-View-Presenter is a good approximation.
Why should I choose to use one instead of the other and in which cases?
I mainly focus on desktop applications and personally speaking I do find the humble dialog box more easy and natural to use.
In MVC, you would still use your "humble" dialog. Except all the business logic for it would be farmed off to another class somewhere else.
http://en.wikipedia.org/wiki/Model-view-controller
You need to weight up whether the investment in MVC will be worth it - especially if you're only working with a single simple dialog.
One of the best discussions I've found regarding the advantages and disadvantages of the model view controller/presenter patterns was written by Martin Fowler: http://martinfowler.com/eaaDev/uiArchs.html
In short, by choosing to use a MVC variant you are increasing the testability of your view (dialog). Keeping all of your logic in your dialog class on the other hand, can be fine if you do not expect that dialog to be very complex, however as the complexity increases, the benefit of testable code increases.
It really is a judgement call.
"Humble" dialogs themselves are already MVC. You have:
M, The content of the dialog's message.
V, The window and widgets the user can see.
C, How the dialog is displayed and how it responds to user activity.
Your GUI framework or wrapper library can provide MVC for you seamlessly without you having to think about it, but it's still MVC.
There is no simple answer.
You should use whatever will make your life easier.
If dialog is really simple, and you know for sure it is going to stay that way, go with humble dialog.
If you have something more complex, like multiple view presentations of the same data, or you know your simple dialog will become more complex over time, then, by all means, use MVC.
You can also take a look ant MVP pattern as an alternative to MVC.