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

6.5 KiB
Raw Permalink Blame History

source_files, generated_at, model, schema_version, sha256
source_files generated_at model schema_version sha256
DataPRO/Modules/Database/DatabaseServices/DatabaseServicesModule.cs
2026-04-16T04:34:59.163908+00:00 Qwen/Qwen3-Coder-Next-FP8 1 674f1fac51c6e6cb

DatabaseServices

Documentation: DatabaseServicesModule


1. Purpose

The DatabaseServicesModule is a Prism module responsible for registering core database-related UI components (views and view models) into the Unity dependency injection container during application startup. It enables modular composition of the database services feature set within the larger application architecture, specifically integrating with Prisms module loading mechanism and Unity for dependency resolution. It also contributes metadata (name, image, group, region) to the main UI for discoverability and placement of database-related components.


2. Public Interface

DatabaseServicesModule class

  • public DatabaseServicesModule(IUnityContainer unityContainer)
    Constructor. Accepts a Unity container via dependency injection and stores it for later use in type registration.

  • public void Initialize()
    Registers the following view/view-model pairs as singleton mappings in the Unity container:

    • IDatabaseCopyViewDatabaseCopyView
    • IDatabaseCopyViewModelDatabaseCopyViewModel
    • IDatabaseStatusBarViewDatabaseStatusBarView
    • IDatabaseStatusBarViewModelDatabaseStatusBarViewModel
    • IDatabaseSwitchViewDatabaseSwitchView
    • IDatabaseSwitchViewModelDatabaseSwitchViewModel
      Note: This method is called both directly by Prisms IModule.Initialize() and indirectly via RegisterTypes().
  • public void OnInitialized(IContainerProvider containerProvider)
    Currently empty; no logic implemented.

  • public void RegisterTypes(IContainerRegistry containerRegistry)
    Delegates to Initialize(). This is required by Prisms IModule interface (via IContainerRegistry), but the implementation ignores containerRegistry and uses the injected _unityContainer instead.

DatabaseServicesModuleNameAttribute class

  • public override string AssemblyName { get; }
    Returns "DatabaseServices" (value of AssemblyNames.DatabaseServices.ToString()).

  • public override string GetAssemblyName()
    Returns the same value as AssemblyName.

  • public override Type GetAttributeType()
    Returns typeof(TextAttribute).

DatabaseServicesModuleImageAttribute class

  • public override BitmapImage AssemblyImage { get; }
    Loads and returns a BitmapImage by calling AssemblyInfo.GetImage("DatabaseServices").

  • public override string AssemblyName { get; }
    Returns "DatabaseServices".

  • public override string AssemblyGroup { get; }
    Returns "Prepare" (value of eAssemblyGroups.Prepare.ToString()).

  • public override eAssemblyRegion AssemblyRegion { get; }
    Returns eAssemblyRegion.DatabaseServicesRegion.

  • public override string GetAssemblyName()
    Returns "DatabaseServices".

  • public override string GetAssemblyGroup()
    Returns "Prepare".

  • public override eAssemblyRegion GetAssemblyRegion()
    Returns eAssemblyRegion.DatabaseServicesRegion.

  • public override BitmapImage GetAssemblyImage()
    Returns the value of AssemblyImage.

  • public override Type GetAttributeType()
    Returns typeof(ImageAttribute).


3. Invariants

  • Singleton Registration: All view/view-model pairs registered in Initialize() are registered as singletons (default Unity behavior for RegisterType<T, TImpl>() without specifying LifetimeManager).
  • Assembly Name Consistency: Both attributes (DatabaseServicesModuleNameAttribute, DatabaseServicesModuleImageAttribute) consistently use "DatabaseServices" as the assembly name (via AssemblyNames.DatabaseServices).
  • Group & Region Constraints:
    • AssemblyGroup is always "Prepare" (from eAssemblyGroups.Prepare).
    • AssemblyRegion is always eAssemblyRegion.DatabaseServicesRegion.
  • Image Loading: AssemblyImage is loaded exactly once per instance (cached in _img), using AssemblyInfo.GetImage("DatabaseServices"). No fallback or error handling is visible in the source.

4. Dependencies

Dependencies of this module:

  • Prism.Modularity (IModule): Required for module discovery and initialization.
  • Unity (IUnityContainer, IContainerProvider, IContainerRegistry): Used for DI container registration.
  • DTS.Common (AssemblyNames, eAssemblyGroups, eAssemblyRegion, AssemblyInfo): Provides metadata constants and image-loading utilities.
  • System.ComponentModel.Composition (Export): Enables Prism to discover this module via MEF.
  • System.Windows.Media.Imaging (BitmapImage): Required for the image attribute.

Dependencies on this module:

  • Prism-based shell/application: The main application must load this module (via Prism module catalog) to register the database services views/view-models.
  • UI regions: The DatabaseServicesRegion (referenced in AssemblyRegion) must be defined elsewhere (e.g., in XAML or shell layout) for views to be injected into.

5. Gotchas

  • Redundant Initialize() call: RegisterTypes() calls Initialize(), but Initialize() is also called directly by Prism. This is safe (idempotent for registration), but indicates potential design redundancy or legacy code.
  • Ignored containerRegistry: RegisterTypes() receives IContainerRegistry containerRegistry but ignores it in favor of the injected _unityContainer. This couples the module to Unity and may break if another DI container is used.
  • No error handling for image loading: If AssemblyInfo.GetImage("DatabaseServices") fails (e.g., missing image resource), _img may be null with no visible fallback or logging.
  • Hardcoded string "DatabaseServices": Used in both attributes and AssemblyInfo.GetImage(). A typo or rename in AssemblyNames.DatabaseServices would cause runtime issues.
  • No OnInitialized() logic: The OnInitialized() method is empty. If initialization order or cross-module coordination is needed, this is currently unsupported.
  • Attribute usage: Both attributes are applied at the assembly level (via [assembly: ...]), meaning they are not tied to the DatabaseServicesModule class itself but to the entire assembly. This may cause confusion if multiple modules exist in the same assembly.

None identified beyond the above.