6.2 KiB
source_files, generated_at, model, schema_version, sha256
| source_files | generated_at | model | schema_version | sha256 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
2026-04-16T03:13:29.049967+00:00 | Qwen/Qwen3-Coder-Next-FP8 | 1 | 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; }ITRLReportOutputView OutputView { get; set; } |
ViewModel for TRL reports; manages binding between input and output views. |
IHeadReportViewModel |
IBaseViewModel |
IHeadReportInputView InputView { get; set; }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/IBaseViewModelbut 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
ITRLReportViewModelmust have bothInputViewandOutputViewassigned (though null assignment is syntactically allowed, it violates intended usage). - An
IHeadReportViewModelmust have bothInputViewandOutputViewassigned. - The
InputViewandOutputViewproperties are read-write (get; set;), implying the view model may reassign views during lifecycle (e.g., for dynamic switching or disposal/reinitialization).
- An
-
View Hierarchy:
- All view interfaces (
ITRLReportInputView,ITRLReportOutputView, etc.) inherit fromIBaseView, implying they share a common base contract (e.g., lifecycle methods, naming, or disposal semantics) defined inDTS.Common.Base. - View models inherit from
IBaseViewModel, suggesting shared ViewModel responsibilities (e.g.,INotifyPropertyChangedsupport, command handling).
- All view interfaces (
-
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.
- There is no shared interface between TRL and Head report views/view models (e.g., no common
4. Dependencies
Dependencies of this module:
DTS.Common.Base(specificallyIBaseViewandIBaseViewModel)- 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.
- This module requires the base interfaces to be defined elsewhere in
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 onDTS.Common.Base. - Report controllers or coordinators (not visible here) would depend on
ITRLReportViewModelandIHeadReportViewModelto 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.)