Внедрение зависимостей java в игровой фреймворк - когда использовать синглтоны

Я пытаюсь понять, как использовать внедрение зависимостей в Play Framework 2.4. Я знаком с общими принципами, но не совсем понимаю их значение для дизайна. Мои общие рассуждения заключались в том, что статические методы в классах контроллеров слишком похожи на использование глобальных переменных и могут легко вызвать проблемы с безопасностью потоков и т. Д., А также в целом поощряют плохой дизайн. Итак, поскольку Play теперь поощряет переход на внедрение зависимостей, я тоже должен переключиться.

Что меня смущает, так это то, что является хорошей практикой в ​​этом контексте. Когда я читаю официальную документацию Play, в ней кратко говорится о внедрении зависимостей, а затем сразу упоминается аннотация @Singleton. И доступный пример (http://www.typesafe.com/activator/template/play-guice) также говорит об одноэлементном классе WelcomeTextGenerator.

Итак, мне интересно, следует ли мне использовать одноэлементные объекты, как, похоже, подразумевают примеры? Если это так, то в чем преимущество по сравнению со старым подходом статических методов? Существуют ли определенные типы объектов (например, контроллеры?), Которые должны быть одиночными, и есть ли последствия для производительности, если не помечать объекты как одиночные?


java dependency-injection singleton playframework-2.4
person myrosia    schedule 21.07.2015    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Итак, мне интересно, следует ли мне использовать одноэлементные объекты, как, похоже, подразумевают примеры? Если это так, то в чем преимущество по сравнению со старым подходом статических методов?

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

По сравнению со статическими методами вы можете использовать все эти причудливые вещи ООП. В основном вопрос заключается в том, «каковы недостатки статических методов?»

Существуют ли определенные типы объектов (например, контроллеры?), Которые должны быть одиночными, и есть ли последствия для производительности, если не помечать объекты как одиночные?

Play или, более конкретно, Guice будет создавать новый объект всякий раз, когда по умолчанию внедряется зависимость. Если пометить их как @Singleton, будет создан только один объект, и один и тот же объект будет повторно использован для всех инъекций. Другими словами: синглтоны сохраняют создание некоторых объектов и сборку мусора, но требуют синхронизации для инициализации объекта.

Чтобы ответить на ваш вопрос, когда использовать @Singleton, как правило (источник):

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

Кстати, Guice предлагает очень полную документацию. Я настоятельно рекомендую просмотреть некоторое время.

person Roman    schedule 22.07.2015
comment
Спасибо - вот что мне было нужно. Я нашел страницу Scopes, на которую вы ссылаетесь, очень полезной. Из документации Play для меня не было очевидно, почему выделялся синглтон или что были другие варианты - это имеет гораздо больший смысл. - person myrosia; 22.07.2015
comment
После небольшого дополнительного исследования потенциальное предупреждение: на странице Scopes Guice рассказывается о области запроса и области сеанса, но, насколько я могу судить, Play не поддерживает их, потому что он не использует реализацию контейнера сервлетов Google и не предоставляет свою собственную сейчас. Таким образом, в этом смысле страница документации может вводить в заблуждение, потому что она не разъясняет зависимости реализации. - person myrosia; 31.07.2015