Replace global singletons/service locators with first-class dependency injection

[tylerkron]

Overview

The WPF app still wires services via static singletons (ConnectionManager, LoggingManager, AppLogger, etc.) and a custom DialogService.ServiceLocator. App.OnStartup mixes manual ServiceCollection setup with that locator, which makes mocking difficult and spreads lifetime management across the codebase.

Task

1. Bootstrap the app with HostApplicationBuilder/GenericHost. Register all services (logging, device management, message consumers/producers, dialogs, EF context factory, view models).
2. Convert singletons to regular classes with interfaces; register them with proper lifetimes.
3. Remove the custom ServiceLocator once everything resolves through DI; update WPF windows/view models to request dependencies via constructor injection/factories.
4. Update background workers/tasks to use injected dependencies instead of static Instance lookups.
5. Adapt tests: build a minimal service provider and inject mocks/fakes.
6. Update developer docs/README with new DI guidance.

Acceptance Criteria

• No static Instance/ServiceLocator usage remains in production code.
• All dependencies resolve through DI and can be overridden in tests.
• Build & tests pass; regression coverage includes ConnectionManager duplicate-device handling and LoggingManager session lifecycle with injected fakes.
• Documentation reflects the new startup/DI model.],

[tylerkron]

Suggested approach: incremental migration

The all-or-nothing scope here is risky — it touches virtually every file and will conflict with the ongoing core migration (Phase 6). Recommend breaking this into smaller, independently shippable PRs:

1. Introduce IHostBuilder + register a few services — keep existing singletons as shims so nothing breaks. This gets the DI container in place without changing any consumers.
2. Migrate one subsystem at a time — e.g., logging first, then connection management, then dialog service. Each PR converts one singleton to a DI-registered service with an interface, updates its consumers to use constructor injection, and removes the static Instance accessor.
3. Remove ServiceLocator last — once nothing depends on it, delete it in a final cleanup PR.

This way each PR is reviewable, testable, and you can pause partway if priorities shift. Suggest deferring until after the core migration (Phase 6) stabilizes to avoid merge conflict churn.

[daqifi-aos]

🔍 Refinement Notes

Gaps

• No migration strategy specified for existing static Instance properties - should they throw exceptions or provide backwards compatibility during transition
• Missing error handling approach when DI container fails to resolve services at startup
• No specification for how Sentry initialization (referenced in App.config) integrates with new DI container
• Unclear how EF migrations and database initialization will work with DI-managed LoggingContext
• Missing guidance on test service provider configuration - which services need real vs fake implementations
• No details on how background threads in DatabaseLogger.ConsumerThread will access DI container scope

Risks

• WPF data binding could break if ViewModelLocator removal affects existing view model resolution patterns
• DatabaseLogger background thread may lose access to EF context if service lifetimes don't align with thread lifecycle
• Circular dependencies between services during DI registration could prevent application startup
• Existing static service access in exception handlers or cleanup code could cause runtime failures during migration

Execution Contract

• Complexity: large
• Required Tools: Microsoft.Extensions.Hosting, Microsoft.Extensions.DependencyInjection
• Affected Files: Daqifi.Desktop/App.xaml.cs, Daqifi.Desktop/ConnectionManager.cs, Daqifi.Desktop/Loggers/LoggingManager.cs, Daqifi.Desktop.Common/Loggers/AppLogger.cs, Daqifi.Desktop/DialogService/ServiceLocator.cs, Daqifi.Desktop/ViewModels/ViewModelLocator.cs, Daqifi.Desktop/MainWindow.xaml.cs, Daqifi.Desktop/Loggers/DatabaseLogger.cs, Daqifi.Desktop/Device/WiFiDevice/DaqifiStreamingDevice.cs, Daqifi.Desktop/Device/SerialDevice/SerialStreamingDevice.cs
• Dependencies: Microsoft.Extensions.Hosting package, Microsoft.Extensions.DependencyInjection package

Open Questions

• How should the existing ViewModelLocator class be migrated - should it become a DI-aware factory or be completely removed?
• What is the intended service lifetime for ConnectionManager and LoggingManager - singleton or scoped?
• How should WPF dialogs instantiated through DialogService receive their view models when ServiceLocator is removed?

---

Refined by DAQiFi AOS at 2026-04-06T04:19:20.645134+00:00