48 lines
4.0 KiB
Markdown
48 lines
4.0 KiB
Markdown
---
|
||
source_files:
|
||
- Common/DTS.Common/Interface/ViewData/IViewDataView.cs
|
||
- Common/DTS.Common/Interface/ViewData/IViewDataViewModel.cs
|
||
generated_at: "2026-04-16T02:59:18.775792+00:00"
|
||
model: "Qwen/Qwen3-Coder-Next-FP8"
|
||
schema_version: 1
|
||
sha256: "bb1cd33bbb5a471b"
|
||
---
|
||
|
||
# ViewData
|
||
|
||
## 1. Purpose
|
||
This module defines the foundational interfaces `IViewDataView` and `IViewDataViewModel` for implementing the View-ViewModel pattern within the DTS (likely *Data Tracking System*) architecture. These interfaces serve as contract markers—extending `IBaseView` and `IBaseViewModel` respectively—to semantically distinguish view and view model types specifically responsible for *view data* concerns (e.g., UI state, presentation logic, data binding payloads). They exist to enforce architectural separation and enable type-based conventions (e.g., dependency injection, view resolution, or validation logic) without adding behavior beyond inheritance.
|
||
|
||
## 2. Public Interface
|
||
No additional public members are declared beyond interface inheritance. The interfaces themselves are empty (marker) interfaces.
|
||
|
||
- **`IViewDataView`**
|
||
`public interface IViewDataView : IBaseView`
|
||
A marker interface indicating that a type represents a *view* dedicated to rendering view data. It inherits all contract obligations of `IBaseView` (not shown here), which may include lifecycle or navigation contracts (e.g., `Initialize`, `Load`, `Unload`), but those are defined externally.
|
||
|
||
- **`IViewDataViewModel`**
|
||
`public interface IViewDataViewModel : IBaseViewModel`
|
||
A marker interface indicating that a type represents a *view model* responsible for encapsulating view data. It inherits all contract obligations of `IBaseViewModel` (not shown here), which may include data binding support, state management, or command interfaces.
|
||
|
||
## 3. Invariants
|
||
- Any type implementing `IViewDataView` must also implement `IBaseView`.
|
||
- Any type implementing `IViewDataViewModel` must also implement `IBaseViewModel`.
|
||
- These interfaces impose *no additional runtime constraints* (e.g., no validation, no required properties/methods beyond base interface contracts).
|
||
- They are intended to be used *exclusively* for view data–related concerns; other view/view model concerns (e.g., navigation, modal dialogs) likely use different specialized interfaces (e.g., `INavigationView`, `IModalViewModel`—inferred from naming convention but not present here).
|
||
|
||
## 4. Dependencies
|
||
- **Depends on**:
|
||
- `DTS.Common.Base.IBaseView` (via `IViewDataView`)
|
||
- `DTS.Common.Base.IBaseViewModel` (via `IViewDataViewModel`)
|
||
*(Exact definitions of `IBaseView` and `IBaseViewModel` are not provided in the source and must be consulted separately.)*
|
||
- **Depended on by**:
|
||
- Likely consumed by DI containers, view/view model registration logic, or framework-level view resolution (e.g., `services.AddTransient<IViewDataView, MyView>()`).
|
||
- May be referenced by conventions in view binding or serialization logic (e.g., filtering view models by `IViewDataViewModel` for data export).
|
||
*(Specific consumers are not visible in the provided source.)*
|
||
|
||
## 5. Gotchas
|
||
- **Ambiguity of base interfaces**: Behavior and obligations of `IBaseView` and `IBaseViewModel` are undefined here; misalignment with their contracts could lead to runtime errors (e.g., if `IBaseView` expects `Initialize()` but `IViewDataView` implementers omit it).
|
||
- **No behavioral guarantees**: As marker interfaces, they provide no compile-time safety—implementers may still violate intended semantics (e.g., a class named `IViewDataViewModel` might handle business logic instead of view data).
|
||
- **Namespace collision risk**: Both interfaces reside in `DTS.Common.Interface`, which is broad; without stricter naming or sub-namespaces (e.g., `DTS.Common.Interface.ViewData`), future interfaces may conflict.
|
||
- **No versioning guidance**: Since interfaces are empty, adding members later would be a breaking change—but no documentation clarifies versioning strategy or migration path.
|
||
- *None identified from source alone.* |