Подходящий жизненный цикл для классов репозитория с использованием Castle Windsor

Question

Когда я начал с Виндзора, я думал, что D будет простым. Теперь это вызывает у меня все больше и больше путаницы.

Хранилище поражает меня как класс с единственным жизненным циклом. У меня должен быть один экземпляр FooRepository для загрузки и сохранения Foos в базе данных при жизни приложения.

Тем не менее, каждый репозиторий содержит ссылку на UnitOfWork, который выполняет грязную проверку, работает с базой данных и т. Д. У UnitOfWork есть жизненный цикл PerWebRequest - для UnitOfWork вообще не имеет смысла быть одиночным, как Например, экземпляр singleton может сбрасывать изменения, внесенные несколькими пользовательскими сеансами одновременно.

Итак, у меня есть одноэлементный FooRepository, содержащий ссылку на UnitOfWork, который в конце сеанса удаляется! Я даже не уверен, какое влияние это окажет на поведение хранилища, но это звучит не очень хорошо.

Может ли кто-нибудь объяснить простым языком (хорошо, может быть, с некоторым кодом) подходящий способ управления жизненным циклом классов Repository и UnitOfWork в веб-приложении?

Answer 1

Практическое правило: компонент не должен зависеть от других компонентов, которые его переживут.

Другими словами, переходный процесс может зависеть от одноэлементного компонента или компонента для каждого веб-запроса, но не отнаоборот.

Способ, которым я подхожу к репозиторию - сценарий UoW - это мой UoW для каждого веб-запроса, но хранилища не имеют состояния и являются временными.

Answer 2

Когда вы говорите «хранилище», я предполагаю, что вы имеете в виду хранилище, которое абстрагирует сеанс Nhibernate.Если так, то это никогда не должно быть синглтоном.Если это одноэлементный поток, несколько потоков запросов будут растоптаны в течение сеанса друг друга.Я лично видел несколько дефектов вокруг этого.Поскольку жизненный цикл Касла по умолчанию одноэлементный, если разработчик забывает явно пометить жизненный цикл компонента, начинают происходить плохие вещи.

В идеале он должен выполняться по запросу (следуя концепции единицы работы).Единственным преимуществом такого подхода является то, что вы включили режим совместимости Asp.net в своем приложении (если это не Asp.net).Другой способ - пометить временное хранилище.Но недостатком этого подхода является то, что Castle будет создавать новый объект репозитория каждый раз, когда компоненту это нужно.