Files
DP44/enriched-qwen3-coder-next/Common/DTS.CommonCore/Interface/DTS.Viewer/Navigation.md

49 lines
4.1 KiB
Markdown
Raw Normal View History

2026-04-17 14:55:32 -04:00
---
source_files:
- Common/DTS.CommonCore/Interface/DTS.Viewer/Navigation/INavigationView.cs
- Common/DTS.CommonCore/Interface/DTS.Viewer/Navigation/INavigationViewModel.cs
generated_at: "2026-04-16T02:32:50.807752+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "3183c8a5d454e0e2"
---
# Navigation
## 1. Purpose
This module defines foundational interfaces for navigation-related view and view model components within the `DTS.Common.Interface` namespace. Specifically, it establishes `INavigationView` as a marker interface extending `IBaseView`, and `INavigationViewModel` as a view model interface that enforces a contract for accessing its associated shell view via the `NavigationView` property. These interfaces serve as abstractions to decouple navigation logic from concrete UI implementations, likely supporting MVVM (Model-View-ViewModel) patterns in a viewer application.
## 2. Public Interface
### `INavigationView`
- **Signature**: `public interface INavigationView : IBaseView`
- **Behavior**: A marker interface indicating that a concrete view class participates in the navigation system. It inherits from `IBaseView`, implying it adheres to the base view contract (e.g., lifecycle, data context, or rendering responsibilities defined elsewhere). No additional members are declared in this interface.
### `INavigationViewModel`
- **Signature**: `public interface INavigationViewModel : IBaseViewModel`
- **Behavior**: Extends `IBaseViewModel` and requires implementers to expose a read-only property `NavigationView` of type `INavigationView`. This property provides access to the *Shell View*—the top-level navigation container (e.g., a window or master layout) that hosts navigation content.
- **Property**:
- `INavigationView NavigationView { get; }`
- **Purpose**: Retrieves the associated navigation shell view.
- **Constraints**: Must not be `null` (implied by documentation and typical usage, though not explicitly stated in source).
## 3. Invariants
- `INavigationView` must be implemented by a class that also satisfies `IBaseView` (inherited contract).
- `INavigationViewModel` must be implemented by a class that also satisfies `IBaseViewModel` (inherited contract).
- For any valid instance of `INavigationViewModel`, the `NavigationView` property must return a non-null reference to an object implementing `INavigationView`.
- The `NavigationView` property is read-only; no setter is defined, implying the association is established at construction and immutable thereafter.
## 4. Dependencies
- **Depends on**:
- `DTS.Common.Base.IBaseView` (via `INavigationView`)
- `DTS.Common.Base.IBaseViewModel` (via `INavigationViewModel`)
- **Depended on by**:
- *Not explicitly stated in the provided source*, but any concrete navigation view/view model implementations (e.g., `ShellView`, `ShellViewModel`) would depend on these interfaces.
- Likely consumed by navigation infrastructure (e.g., a navigation service or router) to bind views and view models, though such consumers are not visible in this file.
## 5. Gotchas
- **Ambiguity in "Shell View"**: The XML documentation states `NavigationView` "Gets the Shell View," but the term *Shell View* is not defined here. Its semantics (e.g., whether it is the root window, a navigation frame, or a specific UI container) are not clarified in the source and must be inferred from context or other modules.
- **No validation guarantees**: While `NavigationView` is expected to be non-null, the interface does not enforce this via contracts or attributes (e.g., `[NotNull]`). Implementers must ensure null-safety.
- **No navigation operations defined**: The interfaces themselves contain no methods for navigation (e.g., `NavigateTo`, `GoBack`). Navigation logic is likely handled by separate services or view model methods outside this scope.
- **No versioning or extensibility hooks**: As minimal marker interfaces, future enhancements (e.g., adding lifecycle callbacks) would require breaking changes unless new interfaces are introduced.
- **None identified from source alone.**