Files
2026-04-17 14:55:32 -04:00

6.8 KiB
Raw Permalink Blame History

source_files, generated_at, model, schema_version, sha256
source_files generated_at model schema_version sha256
DataPRO/Modules/Hardware/AddEditHardware/AddEditHardwareModule.cs
2026-04-16T04:36:26.348285+00:00 Qwen/Qwen3-Coder-Next-FP8 1 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 applications UI. It integrates with the Unity dependency injection container to expose IAddEditHardwareView and IAddEditHardwareViewModel as singleton services, enabling consistent instantiation and composition via Prisms 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 Prisms 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 Prisms 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 Prisms 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.