2016-10-28 3 views
0

Во всех корпоративных/веб-приложениях, над которыми я работал, я вижу объекты Business/service (классы, содержащие бизнес-логику), сделанные singleton.Почему бизнес-объекты сделаны singleton?

Вопрос в том, какое преимущество мы получаем, делая их одноточечными? Я могу думать только об одной причине, т. Е. Сервисные объекты нужны снова и снова и состоят из нескольких других зависимостей. Поэтому для создания этих объектов снова и снова может потребоваться дорогостоящее (временное). Это верно ?

+0

Каким будет отличительный фактор в отдельных случаях? –

+0

@ Elliott Извините, я не получил ваш вопрос – user3198603

+0

Хорошо. Какое преимущество вы получаете, делая их не одиночными? –

ответ

0

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

Услуги, Контроллеры и DAO не переносят/не удерживают какое-либо состояние (данные), , поэтому мы реализуем Singleton для этих классов.

В качестве объектов формы/командных классов/объектов DTO/VO хранятся данные, а мы создаем по одному на каждый запрос (они НЕ одиночные).

В чем преимущество, которое мы получаем, делая их одноточечными?

Сохранение памяти, в противном случае мы могли бы попасть в «OutOfMemoryException» в зависимости от настроенного размера кучи.

Я могу придумать только одну причину: i.e. Служебные объекты нужны снова и снова и состоят из нескольких других зависимостей. Поэтому для создания этих объектов снова и снова может потребоваться дорогостоящее (временное). Это верно ?

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

В корпоративных/веб-приложениях, если вы используете singleton для класса (например, service/controller/DAO/etc ..), класс должен быть потокобезопасным.

+0

В идеале Сервисы, Контроллеры и DAO не должны переносить/удерживать какое-либо состояние (данные). Но если кто-то сохраняет состояние (переменную экземпляра) в одноэлементном режиме, даже по ошибке, это будет проблемой в многопоточной среде. Это недостаток, который я вижу, делая их singleton.Поэтому вот почему мой вопрос в том, что является вредом, если я создаю эти объекты службы также один раз за запрос. – user3198603

+0

Возьмите объект Employee (VO), который не может быть одинарным, поскольку данные будут отличаться для каждого запроса, где в качестве Service/DAO они НЕ держите какое-либо состояние/данные, которые изменяются для каждого запроса. Если вы используете какие-либо классы (например, службы/DAO) в Singleton, вы должны убедиться, что они являются потокобезопасными. – developer

+0

@ user3198603 У этого пользователя есть разъяснения. – developer

0

Да! Токсичные объекты - это дорогостоящая инициатива! Поэтому лучше создать только один экземпляр для всего жизненного цикла приложения!

Смежные вопросы