Alternatives à l'architecture Document/Vue
Les applications MFC utilisent normalement l'architecture Document/Vue pour gérer les informations, les formats de fichier, et la représentation visuelle des données aux utilisateurs.Pour la majorité des applications bureautiques, l'architecture Document/Vue est une architecture appropriée et efficace d'application.Cette architecture sépare les données à afficher et, dans la plupart des cas, simplifier votre application et réduit code redondant.
Toutefois, l'architecture Document/Vue n'est pas appropriée pour certaines situations.Considérez ces exemples :
Si vous déplacez une application écrite en C de fenêtre, vous pouvez terminer un port avant d'ajouter la prise en charge de document/vue à votre application.
Si vous écrivez un utilitaire léger, vous pouvez constater que vous pouvez faire sans l'architecture Document/Vue.
Si votre code d'origine mélange déjà la gestion de données avec l'affichage de données, déplacer le code au document/au modèle de vue n'est pas en valeur l'effort car vous devez séparer les deux.Il est préférable de laisser le code comme est.
Pour créer une application qui n'utilise pas l'architecture Document/Vue, désactivez la case à cocher de Prise en charge de l'architecture Document/Vue à l'étape 1 de l'Assistant Application MFC.Consultez L'Assistant Application MFC pour plus de détails.
[!REMARQUE]
Les application basée sur des boîtes de dialogue produits par l'Assistant Application MFC n'utilisent pas l'architecture Document/Vue, donc la case à cocher de Prise en charge de l'architecture Document/Vue est désactivée si vous sélectionnez le type d'application de dialogue.
Les assistants Visual C++, ainsi que la source et les éditeurs de boîtes de dialogue, utilisez l'application générée comme ils le feraient avec n'importe quelle autre application générée par l'Assistant.l'application peut prendre en charge des barres d'outils, des barres de défilement, et une barre d'état, et a une zone À propos de .Votre application ne signalera pas de modèle de document, et elle contiendra pas de classe de document.
Notez que votre application générée possède une classe d'affichage, CChildView, dérivé d' CWnd.MFC crée et positionne une instance de la classe d'affichage dans les fenêtres frames créées par votre application.MFC applique encore à l'aide d'une fenêtre d'affichage, car elle simplifie positionner et gérer le contenu de l'application.Vous pouvez ajouter du code de peinture au membre d' OnPaint de cette classe.Votre code doit ajouter des barres de défilement à la vue plutôt qu'au frame.
Dans la mesure où l'architecture Document/Vue a fourni par les MFC est chargée d'implémenter plusieurs fonctionnalités de base d'une application, son absence de votre projet signifie que vous êtes chargé d'implémenter de nombreuses fonctionnalités importantes de votre application :
De la manière attendue par l'Assistant Application MFC, le menu pour votre application ne contient qu' New les commandes et d' Exit dans le menu de Fichier .(L'ordre d' New n'est prise en charge uniquement pour les applications MDI, et non des applications SDI sans prise en charge de document/vue.) La ressource menu générées ne prendra pas en charge une liste (les plus récemment utilisés) de MRU.
Vous devez ajouter des fonctions gestionnaires et des implémentations pour toutes les commandes que votre application prend en charge, y compris Ouvrir et Enregistrer dans le menu de Fichier .Les MFC fournissent normalement code pour prendre en charge ces fonctionnalités, mais cette prise en charge est étroitement liées à l'architecture Document/Vue.
La barre d'outils pour votre application, si vous demandiez un, sera minimale.
Il est fortement recommandé d'utiliser l'Assistant Application MFC pour créer des applications sans l'architecture Document/Vue, parce que l'Assistant garantit une architecture correcte MFC.Toutefois, si vous devez éviter d'utiliser l'Assistant, voici plusieurs approches pour ignorer l'architecture Document/Vue dans votre code :
Traitez le document comme annexe inutilisée et implémentez votre code de gestion des données dans la classe d'affichage, comme suggéré ci-dessus.La charge pour le document est relativement faible.Un seul objet de CDocument entraîne une petite surcharge par lui-même, plus la petite surcharge des classes de base, du CCmdTarget et du CObjectde CDocument.Les deux dernières classes sont petites.
Déclaré dans CDocument:
Deux objets d' CString .
Trois BOOLS.
Un pointeur d' CDocTemplate .
Un objet d' CPtrList , qui contient une liste des vues du document.
En outre, le document requiert que la durée pour créer l'objet document, ses objets de vue, une fenêtre frame, et un objet de modèle de document.
Traitez le document et la vue en tant qu'annexes inutilisées.Insérez votre code de gestion des données et de dessin dans la fenêtre frame plutôt que la vue.Cette approche est plus proche du modèle de programmation en langage C.
Substituez les parties de l'infrastructure MFC qui créent le document et la vue pour éliminer les créer du tout.Le processus de création du document commence par un appel à CWinApp::AddDocTemplate.Éliminez cet appel de la fonction membre d' InitInstance de la classe d'application et, à la place, créez une fenêtre frame de InitInstance vous-même.Insérez votre code de gestion des données dans votre classe de fenêtre frame.Le processus de création du document/vue est illustré dans création de document/vue.Il s'agit de travail et requiert une connaissance plus profonde de l'infrastructure, mais il vous libère entièrement de la charge mémoire de document/vue.
L'article MFC : Utilisation des classes de base de données sans document ni vue fournit des exemples plus concrets des alternatives de document/vue dans le contexte des applications de base de données.