Синглтон - это полезно

Question

Если у меня есть объект, который работает в качестве репозитория с Save (), GetProduct (идентификатор продукта) и т. Д., Будет ли хорошей идеей, чтобы это было одноэлементным приложением asp.net.мысль состоит в том, что, поскольку у меня есть много обращений к базе данных, это повысит производительность, потому что не тратится время на воссоздание объекта репозитория каждый раз.Я не видел ничего подобного ни в одном из примеров, так почему же это не так?Спасибо

Answer 1

Только учтите, что синглтон в ASP .net означает, что все пользователи вашего веб-сайта будут использовать его для доступа к данным.Это означает, что вам, вероятно, придется блокировать ваши методы, и это может привести к узким местам.

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

Answer 2

К сожалению, это действительно зависит от того, как вы получаете доступ к вашей базе данных, и как ваш класс репозитория действительно абстрагирует соединения с базой данных и транзакции.

Если вы просто говорите о затратах на создание объекта в памяти для каждого http-запроса, то это не имеет большого значения. Это действительно не стоит рассматривать.

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

В частности, для ORM, таких как Linq to SQL или NHibernate, очень важно то, как вы управляете их сеансами. Обычно, хотя вы не хотите, чтобы область действия «сеанса» или «datacontext» выходила за пределы запроса http, так что нет, синглтон не был бы хорошей идеей, если бы синглтон сам удерживал сеанс БД как синглтон. *

Рассмотрите возможность использования контейнера IoC, например Castle Windsor. Затем изменить «образ жизни» определенного класса (singleton, переходный процесс, на веб-запрос и т. Д.) - это простое изменение конфигурации, которое делает ваше приложение более гибким.

Кроме того, общение с самой БД обходится дороже, чем создание новых объектов в памяти, поэтому, если вы действительно после производительности, подумайте об умном кешировании.

Наконец, при рассмотрении Singletons, подумайте об этом с концептуальной точки зрения, а не с точки зрения производительности. Имеет ли смысл, чтобы этот объект был Singleton?