Ninject, MVC и Session Scope: разумная практика?

Question

Я создаю приложение MVC3 с Entity Framework, где почти все действия разрешены только авторизованным пользователям. Следовательно, мне часто приходится ссылаться на организацию-член. Я экспериментировал с различными способами кеширования члена и придумал довольно быстрый подход. Но я хотел бы получить совет / взгляд на риски / недостатки того, что я делаю.

Я определил фабричный класс для извлечения экземпляра Member, который «зарегистрирован» в Ninject, чтобы я мог использовать его там, где он мне нужен. Привязка Ninject является «областью действия сеанса» (я объясню это чуть позже). Метод фабрики сначала проверяет Session, чтобы увидеть, содержит ли он ранее созданный экземпляр Member. Если Session не выполняет подпрограмму, создает экземпляр из базовой базы данных через EF, сохраняя значение в Session и возвращая его.

Поскольку некоторые из обращений к экземпляру Member являются вызовами EF, я должен был убедиться, что контекст объекта EF также находится в области сеанса (я узнал, как трудно вызывать подпрограммы EF для экземпляра Member, который изначально был создан в другом контексте не работает слишком хорошо). Поскольку фабрика и контекст объекта создаются с помощью Ninject, мне пришлось определить область действия Session для Ninject.

Я нашел фрагмент кода для этого здесь , который я смог изменить в соответствии со своими потребностями. Но это такой простой фрагмент, что мне интересно, есть ли причина, по которой эта возможность не предоставляется "изначально" Ninject (или Ninject MVC). Что заставляет меня задаться вопросом, не преследую ли я проблемы из-за того, что я делаю.

Я понимаю, что в Session есть ряд аспектов хранения вещей, которые вы должны программировать, главным из которых является тот факт, что хранимый объект может «исчезнуть» в любое время (т. Е. Вам всегда нужно иметь способ воссоздать его, когда вы его получите). Но хотя это добавляет достаточно сложности, чтобы я не хотел делать это для большого количества объектов, сделать это для одного объекта Member не так уж сложно.

В любом случае приветствуются советы и отзывы по определению объема сеанса привязки Ninject и сохранению сущностей EF в сеансе для приложения MVC.

Answer 1

Существует несколько причин, по которым в самой Ninject такой области нет:

• Реализация делает невозможным масштабирование приложения.Хотя сеанс можно разделить между несколькими экземплярами IIS, данные в вашей области сеанса не могут, потому что каждый экземпляр IIS имеет свое собственное ядро ​​Ninject.
• Это побудит пользователей использовать его в больших масштабах.Но, как правило, не рекомендуется помещать данные в сеанс, если в этом нет крайней необходимости, потому что они кэшируются в течение длительного времени, и нет механизма, чтобы извлечь их из памяти до истечения времени ожидания сеанса.Это может быстро привести к проблемам с нехваткой памяти.По этой причине данные сеанса следует использовать очень осторожно.
• Предпочтительный способ для данных в области сеанса - добавить их в сеанс и добавить временную привязку к методу, который возвращает эти данные или создает новый экземпляр, если онеще не доступенТаким образом, данные удаляются вместе с сеансом, а не хранятся в памяти некоторое время, пока Ninject не выпустит их.Кроме того, масштабирование приложения поддерживается таким образом.

Нет проблем с вашей реализацией Ninject-wise.Но, как я уже говорил, вы должны быть очень осторожны с помещением данных в сессию.Я думаю, что вам также следует подумать о других способах кеширования данных, которые позволяют исключить данные, прежде чем использовать этот подход, например, с помощью NHibernate, я бы посоветовал изучить кеширование 2-го уровня.Если вы по-прежнему решаете использовать данные сеанса, лучше использовать их в сеансе, а не в области действия сеанса Ninject, поскольку это позволяет масштабировать приложение.