.NET における依存性注入では、サービスのリフトタイムを慎重に考慮する必要があります。シングルトンサービス（例: EventListener）が、スコープ付きサービス（例: DbContext）に直接依存する場合に、一般的な落とし穴が生じます。スコープ付き DbContext をシングルトンの EventProcessor に注入すると、同じ DbContext インスタンスが無限に再利用されることになります。この古い DbContext は、データが最新でない、競合エラーなどの問題を引き起こす可能性があります。推奨されるプラクティスは、EventListener をシングルトンとして維持しつつ、IServiceScopeFactory を注入することです。このファクトリにより、シングルトンの EventProcessor は、必要に応じて新しいスコープを作成し、新しい DbContext を取得できます。あるいは、EventProcessor 自体をスコープ付きリフトタイムで登録することもできます。このシナリオでは、シングルトンの EventListener は IServiceScopeFactory を使用してスコープを作成し、処理するイベントごとにスコープ付き EventProcessor を解決します。最終的に、コアとなる原則は、スコープ付き依存関係をシングルトンに直接注入することを避けることです。シングルトンサービスがスコープ付きサービスへのアクセスを必要とする場合は、IServiceScopeFactory を介して動的に取得する必要があります。同様に、サービスが「スコープ付き」のような特定のライフタイムを必要とする場合は、そのライフタイムで登録され、適切に解決される必要があります。これらのライフタイム管理戦略を理解することで、依存性注入に伴う一般的なエラーを防ぐことができます。