init

enriched-qwen3-coder-next/DataPRO/Modules/Hardware/AddEditHardware.md

@@ -0,0 +1,102 @@
+---
+source_files:
+  - DataPRO/Modules/Hardware/AddEditHardware/AddEditHardwareModule.cs
+generated_at: "2026-04-16T04:36:26.348285+00:00"
+model: "Qwen/Qwen3-Coder-Next-FP8"
+schema_version: 1
+sha256: "05d78156d7f176cf"
+---
+
+# AddEditHardware
+
+### 1. **Purpose**  
+The `AddEditHardwareModule` is a Prism-based modular component responsible for registering the view and view model for the hardware add/edit functionality within the application’s UI. It integrates with the Unity dependency injection container to expose `IAddEditHardwareView` and `IAddEditHardwareViewModel` as singleton services, enabling consistent instantiation and composition via Prism’s module loading infrastructure. Additionally, it defines assembly-level metadata attributes (`AddEditHardwareModuleNameAttribute` and `AddEditHardwareModuleImageAttribute`) that supply identifying information (name, image, group, region) for UI presentation—specifically for listing and rendering the module on the main screen.
+
+---
+
+### 2. **Public Interface**  
+
+#### **Class: `AddEditHardwareModule`**
+- **`public AddEditHardwareModule(IUnityContainer unityContainer)`**  
+  Constructor. Accepts and stores a Unity container reference via dependency injection for later type registration.
+
+- **`public void Initialize()`**  
+  Registers the view and view model types as singletons in the Unity container:
+  - `IAddEditHardwareView → AddEditHardwareView`
+  - `IAddEditHardwareViewModel → AddEditHardwareViewModel`
+
+- **`public void OnInitialized(IContainerProvider containerProvider)`**  
+  Empty implementation. No logic executed during Prism’s `OnInitialized` phase.
+
+- **`public void RegisterTypes(IContainerRegistry containerRegistry)`**  
+  Delegates to `Initialize()` to perform type registration. (Note: Uses `IContainerRegistry` from Prism but internally invokes the legacy `Initialize()` method that operates on `IUnityContainer`.)
+
+#### **Attribute: `AddEditHardwareModuleNameAttribute`**
+- **Inherits from `TextAttribute`**  
+  - **`public override string AssemblyName { get; }`**  
+    Returns `"AddEditHardware"` (via `AssemblyNames.AddEditHardware.ToString()`).
+  - **`public override string GetAssemblyName()`**  
+    Returns the same `AssemblyName` value.
+  - **`public override Type GetAttributeType()`**  
+    Returns `typeof(TextAttribute)`.
+
+#### **Attribute: `AddEditHardwareModuleImageAttribute`**
+- **Inherits from `ImageAttribute`**  
+  - **`public override BitmapImage AssemblyImage { get; }`**  
+    Loads and returns a `BitmapImage` by calling `AssemblyInfo.GetImage("AddEditHardware")`.
+  - **`public override BitmapImage GetAssemblyImage()`**  
+    Returns `AssemblyImage`.
+  - **`public override string AssemblyName { get; }`**  
+    Returns `"AddEditHardware"`.
+  - **`public override string GetAssemblyName()`**  
+    Returns `AssemblyName`.
+  - **`public override string AssemblyGroup { get; }`**  
+    Returns `"Prepare"` (via `eAssemblyGroups.Prepare.ToString()`).
+  - **`public override string GetAssemblyGroup()`**  
+    Returns `AssemblyGroup`.
+  - **`public override eAssemblyRegion AssemblyRegion { get; }`**  
+    Returns `eAssemblyRegion.AddEditHardwareRegion`.
+  - **`public override eAssemblyRegion GetAssemblyRegion()`**  
+    Returns `AssemblyRegion`.
+  - **`public override Type GetAttributeType()`**  
+    Returns `typeof(ImageAttribute)`.
+
+> **Note**: The attributes are applied at the assembly level via `[assembly: ...]` directives and are not tied to instance-based usage.
+
+---
+
+### 3. **Invariants**  
+- The module *must* be loaded by Prism after the Unity container is available (via `RegisterTypes`), and *before* views requiring `IAddEditHardwareView` or `IAddEditHardwareViewModel` are resolved.
+- `AssemblyNames.AddEditHardware` and `eAssemblyGroups.Prepare` and `eAssemblyRegion.AddEditHardwareRegion` must be defined elsewhere (in `DTS.Common` or `DTS.Common.Interface`) and be non-null/valid at runtime for attribute initialization to succeed.
+- `AssemblyInfo.GetImage(...)` must return a non-null `BitmapImage` for `"AddEditHardware"`; otherwise, `AssemblyImage` may be `null`.
+- Type registrations in `Initialize()` are *idempotent* only if Unity allows re-registration of the same mapping (behavior depends on Unity configuration, but no explicit safeguards are present here).
+- The `OnInitialized` method is intentionally empty; no side effects occur during Prism’s `OnInitialized` phase.
+
+---
+
+### 4. **Dependencies**  
+
+#### **Module Dependencies**
+- **`DTS.Common`** and **`DTS.Common.Interface`**  
+  Provide core types: `AssemblyNames`, `eAssemblyGroups`, `eAssemblyRegion`, `AssemblyInfo`, `TextAttribute`, `ImageAttribute`, and the interfaces `IAddEditHardwareView`, `IAddEditHardwareViewModel`.
+- **`Prism.Modularity`** and **`Prism.Ioc`**  
+  Required for `IModule`, `IContainerRegistry`, and `IContainerProvider`.
+- **`Unity`** (`Microsoft.Practices.Unity`)  
+  Required for `IUnityContainer`.
+- **`System.Windows.Media.Imaging`**  
+  Used for `BitmapImage`.
+
+#### **Dependents (Inferred)**
+- The main shell/UI layer likely consumes `AddEditHardwareModuleImageAttribute` metadata to render module cards/tiles on the main screen.
+- Other modules or views may depend on `IAddEditHardwareView` or `IAddEditHardwareViewModel` being registered and available via the container.
+
+---
+
+### 5. **Gotchas**  
+- **Redundant `Initialize()` call**: `RegisterTypes` calls `Initialize()`, but `Initialize()` uses `_unityContainer` directly instead of the `IContainerRegistry containerRegistry` parameter passed to `RegisterTypes`. This suggests legacy or transitional code (e.g., migration from Unity-specific `IUnityContainer` to Prism’s `IContainerRegistry`), and may cause issues if `RegisterTypes` is invoked *before* `_unityContainer` is injected (though Prism guarantees `RegisterTypes` runs first).
+- **No null-safety in attribute constructors**: `AssemblyInfo.GetImage(...)` is called in both the parameterless and string-constructor overloads of `AddEditHardwareModuleImageAttribute`. If `"AddEditHardware"` is not a valid image key, `_img` may be `null`, and `AssemblyImage` will return `null` silently.
+- **Assembly-level attributes**: The attributes are applied at the assembly level and *not* tied to any runtime instance. Their properties are computed once at attribute instantiation time (i.e., during assembly load), not lazily.
+- **Unused `string s` parameter**: Both attribute constructors accept a `string s` parameter that is ignored—likely a remnant of base class expectations.
+- **No validation of view/viewmodel types**: `RegisterType` calls assume `AddEditHardwareView` and `AddEditHardwareViewModel` exist and implement `IAddEditHardwareView`/`IAddEditHardwareViewModel`. A mismatch would only surface at resolution time.
+
+> **None identified from source alone** beyond the above—no obvious logic errors, but the design hints at technical debt in the `RegisterTypes`/`Initialize` interaction.