16,547
社区成员
发帖
与我相关
我的任务
分享VC++6.0、MFC、Application Framework到底是什么，有什么区别与联系？
各位高手：
看书时，分不清楚这三个到底是怎么区别的，请指教。谢谢！
一位新手
看书时，分不清楚这三个到底是怎么区别的，请指教。谢谢！
一位新手
...全文
请发表友善的回复…
发表回复
qing_li73 2002-11-05
- 打赏
- 举报
Print preview and printer support
Support for scrolling windows and splitter windows
Support for toolbars and status bars
Access to Visual Basic controls
Support for context-sensitive help
Support for automatic processing of data entered in a dialog box
An improved interface to OLE version 1.0
DLL support
The MFC library version 2.5 classes (in Visual C++ version 1.5) contributed the following:
Open Database Connectivity (ODBC) support that allows your application to access and update data stored in many popular databases such as Microsoft Access, FoxPro, and Microsoft SQL Server
An interface to OLE version 2.01, with support for in-place editing, linking, drag and drop, and OLE Automation
Visual C++ version 2.0 was the first 32-bit version of the product. It included support for Microsoft Windows NT version 3.5. It also contained MFC version 3.0, which had the following new features:
Tab dialog (property sheet) support (which was also added to Visual C++ version 1.51, included on the same CD-ROM)
Docking control bars that were implemented within MFC
Support for thin-frame windows
A separate Control Development Kit (CDK) for building 16-bit and 32-bit OLE controls, although no OLE control container support was provided
A subscription release, Visual C++ 2.1 with MFC 3.1, added the following:
Support for the new Microsoft Windows 95 (beta) common controls
A new ODBC Level 2 driver integrated with the Access Jet database engine
Winsock classes for TCP/IP data communication
Microsoft decided to skip Visual C++ version 3.0 and proceeded directly to 4.0 in order to synchronize the product version with the MFC version. MFC 4.0 contains these additional features:
New OLE-based Data Access Objects (DAO) classes for use with the Jet engine
Use of the Windows 95 docking control bars instead of the MFC control bars
Full support for the common controls in the released version of Windows 95, with new tree view and rich-edit view classes
New classes for thread synchronization
OLE control container support
Visual C++ 4.2 was an important subscription release that included MFC version 4.2. The following new features were included:
WinInet classes
ActiveX Documents server classes
ActiveX synchronous and asynchronous moniker classes
Enhanced MFC ActiveX Control classes, with features such as windowless activation, optimized drawing code, and so forth
Improved MFC ODBC support, including recordset bulk fetches and data transfer without binding
Visual C++ 5.0 included MFC version 4.21, which fixed some 4.2 bugs. Visual C++ 5.0 introduced some worthwhile features of its own as well:
A redesigned IDE, Developer Studio 97, which included an HTML-based online help system and integration with other languages, including Java
The Active Template Library (ATL) for efficient ActiveX control construction for the Internet
C++ language support for COM (Component Object Model) client programs with the new #import statement for type libraries, as described in Chapter 25
The latest edition of Visual C++, 6.0, includes MFC 6.0. (Notice that the versions are now synchronized again.) Many of the features in MFC 6.0 enable the developer to support the new Microsoft Active Platform, including the following:
MFC classes that encapsulate the new Windows common controls introduced as part of Internet Explorer 4.0
Support for Dynamic HTML, which allows the MFC programmer to create applications that can dynamically manipulate and generate HTML pages
Active Document Containment, which allows MFC-based applications to contain Active Documents
OLE DB Consumers and Providers Template support and Active Data Objects (ADO) data binding, which help database developers who use MFC or ATL
The Learning Curve
All the listed benefits sound great, don't they? You're probably thinking, "You don't get something for nothing." Yes, that's true. To use the application framework effectively, you have to learn it thoroughly, and that takes time. If you have to learn C++, Windows, and the MFC library (without OLE) all at the same time, it will take at least six months before you're really productive. Interestingly, that's close to the learning time for the Win32 API alone.
How can that be if the MFC library offers so much more? For one thing, you can avoid many programming details that C-language Win32 programmers are forced to learn. From our own experience, we can say that an object-oriented application framework makes programming for Windows easier to learn—that is, once you understand object-oriented programming.
The MFC library won't bring real Windows programming down to the masses. Programmers of applications for Windows have usually commanded higher salaries than other programmers, and that situation will continue. The MFC library's learning curve, together with the application framework's power, should ensure that MFC library programmers will continue to be in strong demand.
qing_li73 2002-11-05
- 打赏
- 举报
Why Use the Application Framework?
If you're going to develop applications for Windows, you've got to choose a development environment. Assuming that you've already rejected non-C options such as Microsoft Visual Basic and Borland Delphi, here are some of your remaining options:
Program in C with the Win32 API
Write your own C++ Windows class library that uses Win32
Use the MFC application framework
Use another Windows-based application framework such as Borland's Object Windows Library (OWL)
If you're starting from scratch, any option involves a big learning curve. If you're already a Win16 or Win32 programmer, you'll still have a learning curve with the MFC library. Since its release, MFC has become the dominant Windows class library. But even if you're familiar with it, it's still a good idea to step through the features of this programming choice.
The MFC library is the C++ Microsoft Windows API. If you accept the premise that the C++ language is now the standard for serious application development, you'd have to say that it's natural for Windows to have a C++ programming interface. What better interface is there than the one produced by Microsoft, creator of Windows? That interface is the MFC library.
Application framework applications use a standard structure. Any programmer starting on a large project develops some kind of structure for the code. The problem is that each programmer's structure is different, and it's difficult for a new team member to learn the structure and conform to it. The MFC library application framework includes its own application structure—one that's been proven in many software environments and in many projects. If you write a program for Windows that uses the MFC library, you can safely retire to a Caribbean island, knowing that your minions can easily maintain and enhance your code back home.
Don't think that the MFC library's structure makes your programs inflexible. With the MFC library, your program can call Win32 functions at any time, so you can take maximum advantage of Windows.
Application framework applications are small and fast. Back in the 16-bit days, you could build a self-contained Windows EXE file that was less than 20 kilobytes (KB) in size. Today, Windows programs are larger. One reason is that 32-bit code is fatter. Even with the large memory model, a Win16 program used 16-bit addresses for stack variables and many globals. Win32 programs use 32-bit addresses for everything and often use 32-bit integers because they're more efficient than 16-bit integers. In addition, the new C++ exception-handling code consumes a lot of memory.
That old 20-KB program didn't have a docking toolbar, splitter windows, print preview capabilities, or control container support—features that users expect in modern programs. MFC programs are bigger because they do more and look better. Fortunately, it's now easy to build applications that dynamically link to the MFC code (and to C runtime code), so the size goes back down again—from 192 KB to about 20 KB! Of course, you'll need some big support DLLs in the background, but those are a fact of life these days.
As far as speed is concerned, you're working with machine code produced by an optimizing compiler. Execution is fast, but you might notice a startup delay while the support DLLs are loaded.
The Visual C++ tools reduce coding drudgery. The Visual C++ resource editors, AppWizard, and ClassWizard significantly reduce the time needed to write code that is specific to your application. For example, the resource editor creates a header file that contains assigned values for #define constants. App-Wizard generates skeleton code for your entire application, and ClassWizard generates prototypes and function bodies for message handlers.
The MFC library application framework is feature rich. The MFC library version 1.0 classes, introduced with Microsoft C/C++ version 7.0, included the following features:
A C++ interface to the Windows API
General-purpose (non-Windows-specific) classes, including:
Collection classes for lists, arrays, and maps
A useful and efficient string class
Time, time span, and date classes
File access classes for operating system independence
Support for systematic object storage and retrieval to and from disk
A "common root object" class hierarchy
Streamlined Multiple Document Interface (MDI) application support
Some support for OLE version 1.0
The MFC library version 2.0 classes (in Visual C++ version 1.0) picked up where the version 1.0 classes left off by supporting many user interface features that are found in current Windows-based applications, plus they introduced the application framework architecture. Here's a summary of the important new features:
Full support for File Open, Save, and Save As menu items and the most recently used file list
If you're going to develop applications for Windows, you've got to choose a development environment. Assuming that you've already rejected non-C options such as Microsoft Visual Basic and Borland Delphi, here are some of your remaining options:
Program in C with the Win32 API
Write your own C++ Windows class library that uses Win32
Use the MFC application framework
Use another Windows-based application framework such as Borland's Object Windows Library (OWL)
If you're starting from scratch, any option involves a big learning curve. If you're already a Win16 or Win32 programmer, you'll still have a learning curve with the MFC library. Since its release, MFC has become the dominant Windows class library. But even if you're familiar with it, it's still a good idea to step through the features of this programming choice.
The MFC library is the C++ Microsoft Windows API. If you accept the premise that the C++ language is now the standard for serious application development, you'd have to say that it's natural for Windows to have a C++ programming interface. What better interface is there than the one produced by Microsoft, creator of Windows? That interface is the MFC library.
Application framework applications use a standard structure. Any programmer starting on a large project develops some kind of structure for the code. The problem is that each programmer's structure is different, and it's difficult for a new team member to learn the structure and conform to it. The MFC library application framework includes its own application structure—one that's been proven in many software environments and in many projects. If you write a program for Windows that uses the MFC library, you can safely retire to a Caribbean island, knowing that your minions can easily maintain and enhance your code back home.
Don't think that the MFC library's structure makes your programs inflexible. With the MFC library, your program can call Win32 functions at any time, so you can take maximum advantage of Windows.
Application framework applications are small and fast. Back in the 16-bit days, you could build a self-contained Windows EXE file that was less than 20 kilobytes (KB) in size. Today, Windows programs are larger. One reason is that 32-bit code is fatter. Even with the large memory model, a Win16 program used 16-bit addresses for stack variables and many globals. Win32 programs use 32-bit addresses for everything and often use 32-bit integers because they're more efficient than 16-bit integers. In addition, the new C++ exception-handling code consumes a lot of memory.
That old 20-KB program didn't have a docking toolbar, splitter windows, print preview capabilities, or control container support—features that users expect in modern programs. MFC programs are bigger because they do more and look better. Fortunately, it's now easy to build applications that dynamically link to the MFC code (and to C runtime code), so the size goes back down again—from 192 KB to about 20 KB! Of course, you'll need some big support DLLs in the background, but those are a fact of life these days.
As far as speed is concerned, you're working with machine code produced by an optimizing compiler. Execution is fast, but you might notice a startup delay while the support DLLs are loaded.
The Visual C++ tools reduce coding drudgery. The Visual C++ resource editors, AppWizard, and ClassWizard significantly reduce the time needed to write code that is specific to your application. For example, the resource editor creates a header file that contains assigned values for #define constants. App-Wizard generates skeleton code for your entire application, and ClassWizard generates prototypes and function bodies for message handlers.
The MFC library application framework is feature rich. The MFC library version 1.0 classes, introduced with Microsoft C/C++ version 7.0, included the following features:
A C++ interface to the Windows API
General-purpose (non-Windows-specific) classes, including:
Collection classes for lists, arrays, and maps
A useful and efficient string class
Time, time span, and date classes
File access classes for operating system independence
Support for systematic object storage and retrieval to and from disk
A "common root object" class hierarchy
Streamlined Multiple Document Interface (MDI) application support
Some support for OLE version 1.0
The MFC library version 2.0 classes (in Visual C++ version 1.0) picked up where the version 1.0 classes left off by supporting many user interface features that are found in current Windows-based applications, plus they introduced the application framework architecture. Here's a summary of the important new features:
Full support for File Open, Save, and Save As menu items and the most recently used file list
qing_li73 2002-11-05
- 打赏
- 举报
MFC, ATL, and WFC—Is MFC Dead?
Ever since Microsoft released the Active Template Library (ATL) as part of Visual C++, Windows developers have speculated that the Microsoft Foundation Class Library (MFC) was no longer "en vogue" at Microsoft and that future efforts would focus on newer libraries such as ATL. Recently, Microsoft released another class library, Windows Foundation Classes (WFC), for Java Windows developers, which has unfortunately helped to fan the rumors that "MFC is dead."
The rumors of MFC's demise are definitely premature. Visual C++ 6.0 has added significant functionality to MFC and ATL in parallel, which indicates that both libraries will receive equal attention moving forward. Part of the problem is that the design goals of each library are sometimes not clearly stated and therefore are not clearly understood by the Visual C++ developer. MFC is designed to be a great class library for creating graphically rich, sophisticated Windows applications. ATL is designed to make it easy to create extremely lightweight COM objects and ActiveX controls. Each of these design goals has resulted in a different library to empower the developer.
Another common misconception is that MFC and ATL are mutually exclusive. This is definitely not the case! In fact, it is very easy to create ATL-based COM objects that use MFC. The only issue is that since many developers choose ATL for its lightweight nature, using MFC, which is feature-rich and "heavy," seems to contradict the reason for choosing ATL. While this might be the case for some developers, it doesn't make ATL and MFC mutually exclusive.
While ATL does not replace MFC, we do think it is an important part of Visual C++, so in this edition of Programming Microsoft Visual C++ we have added two chapters that cover the ATL class libraries.
u'll find more via MSDN :)
Enjoy !
Ever since Microsoft released the Active Template Library (ATL) as part of Visual C++, Windows developers have speculated that the Microsoft Foundation Class Library (MFC) was no longer "en vogue" at Microsoft and that future efforts would focus on newer libraries such as ATL. Recently, Microsoft released another class library, Windows Foundation Classes (WFC), for Java Windows developers, which has unfortunately helped to fan the rumors that "MFC is dead."
The rumors of MFC's demise are definitely premature. Visual C++ 6.0 has added significant functionality to MFC and ATL in parallel, which indicates that both libraries will receive equal attention moving forward. Part of the problem is that the design goals of each library are sometimes not clearly stated and therefore are not clearly understood by the Visual C++ developer. MFC is designed to be a great class library for creating graphically rich, sophisticated Windows applications. ATL is designed to make it easy to create extremely lightweight COM objects and ActiveX controls. Each of these design goals has resulted in a different library to empower the developer.
Another common misconception is that MFC and ATL are mutually exclusive. This is definitely not the case! In fact, it is very easy to create ATL-based COM objects that use MFC. The only issue is that since many developers choose ATL for its lightweight nature, using MFC, which is feature-rich and "heavy," seems to contradict the reason for choosing ATL. While this might be the case for some developers, it doesn't make ATL and MFC mutually exclusive.
While ATL does not replace MFC, we do think it is an important part of Visual C++, so in this edition of Programming Microsoft Visual C++ we have added two chapters that cover the ATL class libraries.
u'll find more via MSDN :)
Enjoy !
