87 lines
6.2 KiB
Markdown
87 lines
6.2 KiB
Markdown
---
|
|
source_files:
|
|
- Common/DTS.Common/Interface/Reports/PedestrianAndHead/ITRLReportInputView.cs
|
|
- Common/DTS.Common/Interface/Reports/PedestrianAndHead/ITRLReportOutputView.cs
|
|
- Common/DTS.Common/Interface/Reports/PedestrianAndHead/IHeadReportInputView.cs
|
|
- Common/DTS.Common/Interface/Reports/PedestrianAndHead/IHeadReportOutputView.cs
|
|
- Common/DTS.Common/Interface/Reports/PedestrianAndHead/ITRLReportViewModel.cs
|
|
- Common/DTS.Common/Interface/Reports/PedestrianAndHead/IHeadReportViewModel.cs
|
|
generated_at: "2026-04-16T03:13:29.049967+00:00"
|
|
model: "Qwen/Qwen3-Coder-Next-FP8"
|
|
schema_version: 1
|
|
sha256: "2540e87defef7d53"
|
|
---
|
|
|
|
# PedestrianAndHead
|
|
|
|
## Documentation: Pedestrian and Head Report View/ViewModel Interfaces
|
|
|
|
---
|
|
|
|
### 1. Purpose
|
|
This module defines the core view and view model interfaces for two report types—**TRL (Traffic Light) Reports** and **Head (Pedestrian Head) Reports**—within the DTS reporting subsystem. These interfaces establish a standardized contract for UI components that present input and output data for pedestrian and head-related traffic analysis, following the MVVM (Model-View-ViewModel) pattern. The interfaces themselves contain no implementation logic; they serve as structural abstractions to decouple UI layers from business logic and ensure consistent integration across modules consuming or rendering these reports.
|
|
|
|
---
|
|
|
|
### 2. Public Interface
|
|
|
|
#### Interfaces (All in namespace `DTS.Common.Interface`)
|
|
|
|
| Interface | Base Interface | Properties | Description |
|
|
|-----------|----------------|------------|-------------|
|
|
| `ITRLReportInputView` | `IBaseView` | — | Marker interface for the *input* UI view of a TRL report (e.g., configuration or parameter entry screen). |
|
|
| `ITRLReportOutputView` | `IBaseView` | — | Marker interface for the *output* UI view of a TRL report (e.g., results display or visualization). |
|
|
| `IHeadReportInputView` | `IBaseView` | — | Marker interface for the *input* UI view of a Head (pedestrian head) report. |
|
|
| `IHeadReportOutputView` | `IBaseView` | — | Marker interface for the *output* UI view of a Head report. |
|
|
| `ITRLReportViewModel` | `IBaseViewModel` | `ITRLReportInputView InputView { get; set; }`<br>`ITRLReportOutputView OutputView { get; set; }` | ViewModel for TRL reports; manages binding between input and output views. |
|
|
| `IHeadReportViewModel` | `IBaseViewModel` | `IHeadReportInputView InputView { get; set; }`<br>`IHeadReportOutputView OutputView { get; set; }` | ViewModel for Head reports; manages binding between input and output views. |
|
|
|
|
> **Note**: All interfaces are *marker interfaces*—they inherit from `IBaseView`/`IBaseViewModel` but define no additional members beyond property contracts in the view models. Actual behavior (e.g., data loading, rendering, validation) is implemented by concrete types outside this module.
|
|
|
|
---
|
|
|
|
### 3. Invariants
|
|
|
|
- **View-ViewModel Coupling**:
|
|
- An `ITRLReportViewModel` *must* have both `InputView` and `OutputView` assigned (though null assignment is syntactically allowed, it violates intended usage).
|
|
- An `IHeadReportViewModel` *must* have both `InputView` and `OutputView` assigned.
|
|
- The `InputView` and `OutputView` properties are read-write (`get; set;`), implying the view model may reassign views during lifecycle (e.g., for dynamic switching or disposal/reinitialization).
|
|
|
|
- **View Hierarchy**:
|
|
- All view interfaces (`ITRLReportInputView`, `ITRLReportOutputView`, etc.) inherit from `IBaseView`, implying they share a common base contract (e.g., lifecycle methods, naming, or disposal semantics) defined in `DTS.Common.Base`.
|
|
- View models inherit from `IBaseViewModel`, suggesting shared ViewModel responsibilities (e.g., `INotifyPropertyChanged` support, command handling).
|
|
|
|
- **No Cross-Report Assumptions**:
|
|
- There is *no* shared interface between TRL and Head report views/view models (e.g., no common `IPedestrianReportView`), indicating they are treated as independent report types with no polymorphic interchangeability.
|
|
|
|
---
|
|
|
|
### 4. Dependencies
|
|
|
|
#### Dependencies *of* this module:
|
|
- `DTS.Common.Base` (specifically `IBaseView` and `IBaseViewModel`)
|
|
- This module *requires* the base interfaces to be defined elsewhere in `DTS.Common.Base`. Their behavior (e.g., `Initialize()`, `Dispose()`, property change notifications) is assumed but not specified here.
|
|
|
|
#### Dependencies *on* this module:
|
|
- Any module implementing or consuming TRL/Head reports (e.g., report generation services, UI shells, or view factories) will depend on these interfaces.
|
|
- Concrete implementations of these interfaces (e.g., `TRLReportInputView : ITRLReportInputView`) will depend on UI frameworks (e.g., WPF, WinForms, or MAUI) and likely on `DTS.Common.Base`.
|
|
- Report controllers or coordinators (not visible here) would depend on `ITRLReportViewModel` and `IHeadReportViewModel` to wire up views.
|
|
|
|
---
|
|
|
|
### 5. Gotchas
|
|
|
|
- **No Behavior Specification**:
|
|
These interfaces are *purely structural*. They convey no information about data flow, validation rules, or user interactions. Consumers must inspect concrete implementations to understand actual behavior (e.g., how input data is validated or how output is rendered).
|
|
|
|
- **Ambiguous "Head" Terminology**:
|
|
The term "Head" is used without clarification in interface names (`IHeadReport*`). Based solely on the source, it is unclear whether "Head" refers to *pedestrian head counts*, *traffic headway*, *vehicle headlamps*, or another domain concept. Consult domain experts or downstream code for disambiguation.
|
|
|
|
- **No Versioning or Extensibility Hooks**:
|
|
Interfaces are minimal and lack extensibility points (e.g., no generic type parameters, no event interfaces). Adding new capabilities (e.g., progress reporting, export support) may require breaking changes.
|
|
|
|
- **No Invariants on View Assignment**:
|
|
While the view models *expect* both views to be set, there is no runtime enforcement (e.g., no null checks in setters). Attempting to use a view model with unassigned views may cause runtime errors (e.g., `NullReferenceException`).
|
|
|
|
- **None identified from source alone.**
|
|
*(Note: The above gotchas are inferred from common patterns in MVVM architectures and interface design—not from explicit source warnings.)* |