--- 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()`). - 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.*