Если вы просто хотите сослаться на DbContext в вашем Web API + Background Workers, тогда я не понимаю, в чем проблема: просто ссылайтесь на общий проект из ваших рабочих проектов. Судя по вашему сообщению, проблема заключается в том, что внедрение службы, которое вы успешно используете в Web API, не работает с фоновыми рабочими службами. (Предполагая Windows Службы?)
Вместо этого начните с более простого сценария. Инициируйте DbContext внутри службы, когда он используется, а не вводите его.
Т.е.
using(var context = new DataContext("DefaultConnection"))
{
// ...
}
Ваша конфигурация строки подключения должна идентифицировать NPG SQL в качестве поставщика, если эта конфигурация все настроено в вашей конфигурации служб, тогда DBContext должен быть в состоянии настроить по имени строки подключения. Если это сработает, то, вероятно, будет другой механизм для инъекций. Из того, что я мог быстро найти, кажется, что примеры использовали шаблон локатора службы для разрешения зависимостей, я не знаю, есть ли лучшие варианты в наши дни для Windows Служб.
Если внедрение не действительно вариант и вам придется прибегнуть к реализациям, подобным локаторам служб, тогда я, вероятно, рассмотрю что-то вроде шаблона внедрения Lazy Property, который я использовал в прошлом:
public class WorkerService
{
private readonly IContainer _container = null;
public WorkerService(IContainer container)
{
_container = container ?? throw new ArgumentNullException("container");
}
private IDataContextFactory _contextFactory = null;
public IDataContextFactory ContextFactory
{
get { return _contextFactory ?? (_contextFactory = _container.Resolve<IDataContextFactory>()); }
set { _contextFactory = value; }
}
public void Execute()
{
using(var context = ContextFactory.Create()) // returns a DataContext.
{
// do stuff.
}
}
}
Где IContainer представляет интерфейс контракта для вашего данная структура DI. (Unity, Autofa c, et c.)
Альтернативно, единица работы для определения объема DbContext. Поскольку экземпляр службы будет работать долго, мы не хотим внедрять или разрешать DbContext, а скорее фабрику контекста, которую мы можем использовать для получения инициализированного DbContext, который можно использовать при утилизации. Обычно с веб-запросами экземпляр ограничивается запросом и удаляется контейнером в конце запроса. С помощью сервиса мы хотим обеспечить регулярную утилизацию DbContext. DI может быть настроен так, чтобы возвращались временные экземпляры контекста, но эти экземпляры должны быть расположены, что означает, что он не подходит для внедрения конструктора, а скорее через локатор службы. Если бы один экземпляр DbContext использовался и внедрялся в конструктор службы, он работал бы до тех пор, пока служба не остановилась, и увидел бы, что DbContext становится все медленнее и медленнее с течением времени из-за отслеживаемых объектов.