Alternatywy dla architektury dokument/widok

Aplikacje MFC zwykle używają architektury dokumentu/widoku do zarządzania informacjami, formatami plików i wizualną reprezentacją danych dla użytkowników. W przypadku większości aplikacji klasycznych architektura dokumentu/widoku jest odpowiednią i wydajną architekturą aplikacji. Ta architektura oddziela dane od wyświetlania, a w większości przypadków upraszcza aplikację i zmniejsza nadmiarowy kod.

Jednak architektura dokumentu/widoku nie jest odpowiednia w niektórych sytuacjach. Rozważ następujące przykłady:

• Jeśli przenosisz aplikację napisaną w języku C dla systemu Windows, warto ukończyć port przed dodaniem obsługi dokumentu/widoku do aplikacji.

• Jeśli piszesz lekkie narzędzie, możesz to zrobić bez architektury dokumentu/widoku.

• Jeśli oryginalny kod już miesza zarządzanie danymi z wyświetlaniem danych, przeniesienie kodu do modelu dokumentu/widoku nie jest warte wysiłku, ponieważ należy oddzielić te dwa. Możesz wolisz pozostawić kod w następujący sposób.

Aby utworzyć aplikację, która nie korzysta z architektury dokumentu/widoku, wyczyść pole wyboru Obsługa architektury dokumentu/widoku w kroku 1 Kreatora aplikacji MFC. Aby uzyskać szczegółowe informacje, zobacz Kreator aplikacji MFC.

Uwaga

Aplikacje oparte na oknach dialogowych utworzonych przez Kreatora aplikacji MFC nie korzystają z architektury dokumentu/widoku, dlatego pole wyboru Obsługa architektury dokumentu/widoku jest wyłączone, jeśli wybierzesz typ aplikacji okna dialogowego.

Kreatory języka Visual C++, a także edytory źródłowych i dialogowych, współpracują z wygenerowaną aplikacją tak samo jak w przypadku każdej innej aplikacji wygenerowanej przez kreatora. Aplikacja może obsługiwać paski narzędzi, paski przewijania i pasek stanu oraz pole Informacje . Aplikacja nie zarejestruje żadnych szablonów dokumentów i nie będzie zawierać klasy dokumentów.

Pamiętaj, że wygenerowana aplikacja ma klasę widoków , CChildViewpochodzącą z CWndklasy . MFC tworzy i umieszcza jedno wystąpienie klasy widoku w oknach ramowych utworzonych przez aplikację. MFC nadal wymusza korzystanie z okna widoku, ponieważ upraszcza pozycjonowanie zawartości aplikacji i zarządzanie nią. Możesz dodać kod malowania do OnPaint składowej tej klasy. Kod powinien dodać paski przewijania do widoku, a nie do ramki.

Ponieważ architektura dokumentu/widoku zapewniana przez MFC jest odpowiedzialna za implementację wielu podstawowych funkcji aplikacji, jej brak w projekcie oznacza, że odpowiadasz za implementację wielu ważnych funkcji aplikacji:

• Zgodnie z instrukcjami Kreatora aplikacji MFC menu aplikacji zawiera tylko polecenia Nowe i Zakończ w menu Plik . (Nowe polecenie jest obsługiwane tylko w przypadku aplikacji MDI, a nie aplikacji SDI bez obsługi dokumentów/widoków. Wygenerowany zasób menu nie będzie obsługiwał listy MRU (ostatnio używanej).

• Należy dodać funkcje i implementacje programu obsługi dla wszystkich poleceń, które będą obsługiwane przez aplikację, w tym otwórz i zapisz w menu Plik . MFC zwykle udostępnia kod do obsługi tych funkcji, ale obsługa ta jest ściśle powiązana z architekturą dokumentu/widoku.

• Jeśli zażądano, pasek narzędzi aplikacji będzie minimalny.

Zdecydowanie zaleca się użycie Kreatora aplikacji MFC do tworzenia aplikacji bez architektury dokumentu/widoku, ponieważ kreator gwarantuje poprawną architekturę MFC. Jeśli jednak nie musisz używać kreatora, poniżej przedstawiono kilka metod pomijania architektury dokumentu/widoku w kodzie:

• Traktuj dokument jako nieużywany dodatek i zaimplementuj kod zarządzania danymi w klasie widoków, jak pokazano powyżej. Obciążenie dokumentu jest stosunkowo niskie. Pojedynczy obiekt CDocument wiąże się z niewielką ilością nakładu pracy, a także niewielkie obciążenie CDocumentklas bazowych, CCmdTarget i CObject. Obie te ostatnie klasy są małe.

  Zadeklarowane w pliku CDocument:

  • Dwa CString obiekty.

  • Trzy BOOLs.

  • Jeden CDocTemplate wskaźnik.

  • Jeden CPtrList obiekt, który zawiera listę widoków dokumentu.

  Ponadto dokument wymaga czasu na utworzenie obiektu dokumentu, jego obiektów widoku, okna ramki i obiektu szablonu dokumentu.

• Traktuj zarówno dokument, jak i widok jako nieużywane dodatki. Umieść zarządzanie danymi i rysowanie kodu w oknie ramki, a nie w widoku. Takie podejście jest bliżej modelu programowania w języku C.

• Zastąpij części struktury MFC, które tworzą dokument i widok, aby w ogóle je wyeliminować. Proces tworzenia dokumentu rozpoczyna się od wywołania metody CWinApp::AddDocTemplate. Wyeliminuj to wywołanie z funkcji składowej InitInstance klasy aplikacji, a zamiast tego utwórz w sobie okno InitInstance ramki. Umieść kod zarządzania danymi w klasie okna ramowego. Proces tworzenia dokumentu/widoku jest zilustrowany w sekcji Tworzenie dokumentu/widoku. Jest to bardziej praca i wymaga głębszego zrozumienia struktury, ale zwalnia cię całkowicie z nakładu pracy nad dokumentem/widokiem.

Artykuł MFC: Używanie klas baz danych bez dokumentów i widoków zawiera bardziej konkretne przykłady alternatywnych dokumentów/widoków w kontekście aplikacji baz danych.

Zobacz też

Architektura dokumentu/widoku