Комментарии 9
А какое у вас время жизни репозиториев? Singletone или на запрос?
Если Singletone, то в текущем варианте будут проблемы с многопоточным доступом, так как контекст будет шариться между запросами.
Если время жизни на запрос, то произойдёт утечка коннекций, потому что нет dispose контекстов
Ну, поскольку объекты репозиториев создаются в момент генерации объекта контроллера, то они живы пока контроллер отрабатывает обращение к странице, потом вместе с ним и убиваются. А соединения с СУБД в ASP.NET по идее не убиваются сразу, а хранятся в некоем пуле соединений и по необходимости оттуда и берутся. Т.е. их не должно быть сильно больше чем максимальное количество одновременно работающих пользователей.
Всегда диспозил контекст. Решил немного погуглить и набрёл на статью, в которой объяснено, почему диспозить не обязательно, но всё же это можно считать хорошим паттерном. https://blog.jongallant.com/2012/10/do-i-have-to-call-dispose-on-dbcontext/
Удалено
Почему бы не оставить, уже давно оставленный asp.net и понять, что это устарело уже давно. Есть .net core, где это все под капотом есть.
Ну вот руки дойдут, перепишу данные пример под .NET Core, можно будет сделать сравнение с тем, что было и тем как стало.
Уже давно все сравнено и написано. .net core уже давно в продакшене трудится. Додо пицца и 2гис используют его. Вы до сих пор пишете статьи о продукте 10 давности. Бывают ещё вопросы, что учить и ни одного ответа в защиту старого asp.net не увидел.
Да я уже понял из обсуждений предыдущей статьи. Переползу и на .NET Core, пока очередная вундервафля и её не заменит. Не надо только разжигать холивар — какая технология лучше. Почему среди ИТ-шников так много хейтеров и холиварщиков? За прошлую статью мне вкорячили 6 минусов в рейтинг и 2 в карму и спасибо добрым людям, которые вернули ситуацию к тому что было в начале. Ладно бы я там накосячил и сделал всё плохо и статья была бы написана отвратно. Так нет же — только за использование устаревших технологий. Тут тоже специально пометил в спойлере, что лучше использовать .NET Core, хорошо хоть минусов не нахватал пока.
Я работаю в компании, в которой до сих пор в ходу технологии 10-20 летней давности, а мне будут рассказывать про «устаревшие» технологии. У нас до сих пор большинство ERP-систем на SAP R/3 версии 4.0 работают.
Я работаю в компании, в которой до сих пор в ходу технологии 10-20 летней давности, а мне будут рассказывать про «устаревшие» технологии. У нас до сих пор большинство ERP-систем на SAP R/3 версии 4.0 работают.
- try catch {} плохая практика
- Сейчас принято писать асинхронные методы, да и хорошая практика для сервера
Ваша абстракция понятна, только, я не помню в своем случае когда коня/ORM меняли на переправе. Будут сидеть на EF до конца. Учитывая что абстракции резко ухудшают производительность как самой программы так и программистов, я бы задумался нужны ли они в таком виде. DbContext уже сам по себе неслабый репозиторий. Пряча от разработчиков LINQ, вы просто усложняете себе жизнь. IMHO, абстракции лучше строить на уровне бизнес задач/сервисов и в крайнем случае над отдельными сущностями.
Простой пример, что вы сделаете когда надо достать Id первых 100 пользователей, у которых установлен язык английский? Что вам дадут два репозитория которые возвращают целые таблицы в память, а вам нужно достать всего сотню целых чисел из данных связанных двумя таблицами?
Тут приходит на помощь LINQ, репозитории могут возвращать IQueryable. Только зачем эти репозитории тогда, если они просто враппер над DbContext? Я, например, не вижу в них смысла, это ухудшает читабельность, нагружает контроллер дополнительными зависимостями. Если контроллер большой, в него ижектят с 20-к репозиториев, несмотря на то что в основном нужны только несколько на один запрос.
Слегка сумбурно, но это я сейчас наблюдаю во всех ASP.NET проектах в которых просят помочь разобраться с производительностью. Написано по патернам, которые я бы уже и сам назвал антипатернами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET MVC — Entity Framework, MySQL и использование Dependency Resolver для выбора репозитория