---
source_files:
  - Common/DTS.Common/Interface/DTS.Viewer/Navigation/INavigationView.cs
  - Common/DTS.Common/Interface/DTS.Viewer/Navigation/INavigationViewModel.cs
generated_at: "2026-04-16T03:07:38.322183+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "2a3c86a0916b7d5f"
---

# Navigation

## 1. Purpose  
This module defines the foundational interfaces for navigation-related view and view model components within the DTS Viewer subsystem. Specifically, `INavigationView` and `INavigationViewModel` establish a contract for navigation UI layers, enforcing a separation of concerns where the view (UI layer) is bound to a view model (logic/data layer), with the view model exposing a reference back to its associated view. These interfaces extend base abstractions (`IBaseView`, `IBaseViewModel`) to integrate into a larger MVVM (Model-View-ViewModel) architecture, enabling consistent navigation state management and view coordination.

## 2. Public Interface  

### `INavigationView`  
- **Signature**: `public interface INavigationView : IBaseView { }`  
- **Behavior**: Represents the UI layer for navigation functionality. It inherits from `IBaseView`, implying it adheres to the base view contract (e.g., lifecycle, binding context, or rendering responsibilities), but contains no additional members itself. Its purpose is to serve as a typed marker interface for navigation-specific views.

### `INavigationViewModel`  
- **Signature**: `public interface INavigationViewModel : IBaseViewModel`  
  - **Property**: `INavigationView NavigationView { get; }`  
- **Behavior**: Represents the view model for navigation logic. It exposes a read-only property `NavigationView` that provides access to the associated `INavigationView` instance. This enables the view model to interact with or query the view (e.g., for navigation commands, state updates, or coordination), while maintaining loose coupling through the interface.

## 3. Invariants  
- `INavigationView` must be implemented by a concrete view class (e.g., a XAML page or control) that participates in the navigation flow.  
- `INavigationViewModel` must be implemented by a view model class that maintains a reference to an instance of a type implementing `INavigationView`.  
- The `NavigationView` property in `INavigationViewModel` must return a non-null reference to the view instance it is bound to (or has been associated with) during the view-model/view lifecycle.  
- Both interfaces extend their respective base interfaces (`IBaseView`, `IBaseViewModel`), so all invariants of those base interfaces (e.g., binding context requirements, disposal patterns) apply transitively.

## 4. Dependencies  
- **Depends on**:  
  - `DTS.Common.Base.IBaseView` (via `INavigationView`)  
  - `DTS.Common.Base.IBaseViewModel` (via `INavigationViewModel`)  
- **Depended on by**:  
  - Concrete implementations of navigation views (e.g., `ShellView`, `MainMenuView`) will implement `INavigationView`.  
  - Concrete navigation view models (e.g., `ShellViewModel`, `NavigationViewModel`) will implement `INavigationViewModel`.  
  - Other modules (e.g., navigation service, shell host, or region manager) likely depend on `INavigationViewModel` to access or coordinate the navigation UI.  
- *Note*: The source files do not specify concrete consumers, but the design strongly suggests usage in a view model locator or navigation framework (e.g., Prism, MVVM Light, or custom).

## 5. Gotchas  
- The interfaces are intentionally minimal and serve as *marker interfaces*—they convey semantic meaning (navigation context) but no behavior. Consumers must rely on other mechanisms (e.g., commands, events, or additional interfaces) for actual navigation logic.  
- The `NavigationView` property in `INavigationViewModel` is read-only, implying the view reference is set once (e.g., during view-model initialization or binding) and not expected to change. Reassignment may break assumptions in consuming code.  
- No explicit thread-safety or lifecycle guarantees are defined for the `NavigationView` reference; callers should assume it is valid only during the active lifetime of the view/view-model pair.  
- None identified from source alone.