Конфигурация SimpleInjector для шаблонов WebApi и UnitOfWork

Question

Я прочитал документацию SimpleInjector несколько раз. Но имейте несколько вопросов.

Контекст:

• 3 уровня приложения (презентация (MVC + контроллеры API), сервис (бизнес-логика), данные (хранилища, организации и т.д.)
• Единица работы представляет собой тонкую оболочку вокруг EF-х DbContext
• мой DbContext и единица работы регистрируются PerWebRequest, используя RegisterWebApiRequest вызывает исключение, поскольку единица работы используется вне запросов Web API.
• мои MVC и Api контроллеры зарегистрированы с использованием RegisterWebApiControllers (GlobalConfiguration.Configuration) и RegisterMvcControllers (Assembly.GetExecutingAssembly())
• Каждый контроллер имеет один или несколько услуг, инжектированных в него.
• Каждая служба имеет один или несколько хранилищ, введенных в нее.
• У службы также может быть введена другая услуга.
• Я хочу, чтобы тот же Unit of Work/DbContext существовал во всех моих сервисах/хранилищах.

Вопросы:

• Поскольку я использую услуги в моих контроллеров MVC, а также контроллеры API; означает ли это, что я не могу использовать RegisterWebApiRequest вместо RegisterPerWebRequest?

• ни одна из моих служб, репозиториев и т. Д. Не поддерживает любое состояние, я получал бы такую ​​же функциональность, используя PerWebRequest как Transient; есть ли преимущество использования PerWebRequest по сравнению с переходным процессом?

Answer 1

Прочтите следующие q/a: How to configure simple injector container and lifestylse in a MVC web app with WebAPI, WCF, SignalR and Background Tasks. Ответ объясняется тем, что:

1. Внедрение веб-API в тот же проект, что и ваши контроллеры MVC, является плохой идеей с архитектурной точки зрения.
2. Но если вы хотите это сделать, вы можете использовать WebRequestLifestyle в обоих типах приложений. WebApiRequestLifestyle означает стиль жизни, который работает для веб-API как для IIS, так и для самостоятельной среды размещения, но поскольку вы разместили контроллеры Web API в одном проекте, вас явно интересует только IIS-хостинг; в этом случае WebRequestLifestyle будет прекрасно.

Поскольку я использую услуги в моих контроллеров MVC, а также контроллеры API; означает ли это, что я не могу использовать RegisterWebApiRequest вместо RegisterPerWebRequest?

Оба образа жизни используют другой способ кеширования.WebRequestLifestyle использует словарь HttpContext.Current.Items для хранения своего экземпляра SimpleInjector.Scope, тогда как WebApiRequestLifestyle использует класс CallContext для хранения Scope в течение всего срока службы одной асинхронной операции.

Так же, как WebRequestLifestyle может использоваться при разрешении контроллеров Web API, вы также можете использовать WebApiRequestLifestyle (или базовый ExecutionContextScopeLifestyle) для контроллеров MVC. Но если вы хотите этого, вы создадите свою собственную реализацию IDependencyResolver для MVC, которая будет явно запускать и завершать ExecutionContextScope. Отсутствие Scope, хранящееся в CallContext, является причиной отказа в работе контроллеров MVC при регистрации услуг с использованием WebApiRequestLifestyle. Но хотя в MVC можно использовать WebApiRequestLifestyle, наоборот, гораздо проще, так как не требуется никакого специального кода.

Ни одна из моих служб, репозиториев и т. Д. Не поддерживает какое-либо состояние, я бы получил такую ​​же функциональность, используя PerWebRequest как Transient; есть ли преимущество использования PerWebRequest по сравнению с переходным процессом?

Если услуги не имеют состояния, не имеет значения, какой у них образ жизни. Единственное ограничение состоит в том, что у них есть зависимости, у которых есть образ жизни, который равен или длиннее своего. Нарушение этого ограничения называется Captive Dependencies и может вызвать всевозможные проблемы. Поскольку неактивные зависимости плохие, Simple Injector v3 проверяет и предотвращает это для вас.

Возможно, вы можете сделать все объекты в вашей области с ограниченной видимостью (не временные), что делает их переходными, как правило, легче настраивать и может привести к повышению производительности (хотя вы, вероятно, никогда не заметите разницы в реальной жизни).