1. 
   Что такое бин?
   
   
   

Bean в Spring — это объекты, образующие основу приложения и управляемые контейнером (контейнер = интерфейсы и абстр. классы) Spring IoC. Бином является почти все в Spring - сервисы, контроллеры, репозитории, по сути все приложение состоит из набора бинов, в которых описывается бизнес-логика.
@Bean - аннотация Spring Framework, она используется над методом для указания того, что данный метод создает, настраивает и инициализирует новый объект, управляемый Spring IoC контейнером. Такие методы можно использовать как в классах с аннотацией @Configuration, так и в классах с аннотацией @Component (или её наследниках).
После создания бина операторы new нам не понадобятся, мы будем работать в классе-бине с его полями-бинами так, будто они уже инициированы (только с теми полями, которые сконфигурированы как бины. Остальные инициализируются как обычно, в том числе с помощью оператора new.)

2. 
   Виды бинов?
   

Область видимости бинов (scope):

1.Singleton - является дефолтным scope. В контейнере будет создан только один бин, и все запросы на него будут возвращать один и тот же бин (закэшированный экземпляр). Потокобезопасный, создается сразу при сканировании. Singleton bean можно внедрять в любой другой бин. В сам singleton можно внедрить только prototype или singleton.
2.Prototype - создается каждый раз, когда он запрашивается. Spring не вызывает метод destroy(). Spring не берет на себя контроль полного жизненного цикла бина и не хранит такие бины в своём контейнере, а отдаёт их клиенту и больше о них не заботится (в отличие от singleton-бинов). Не потокобезопасный, создается только после запроса, может быть зависимостью для любого бина. Внедрять можно только prototype или singleton. не отработает предестрой

3.Request - создается новый экземпляр для каждого HTTP-запроса. Таким образом, если сервер в настоящее время обрабатывает 50 запросов, тогда контейнер может иметь не более 50 бинов, по одному для каждого HTTP-запроса. Экземпляры уничтожаются, как только HTTP-запрос завершен.
4.Session - создается в одном экземпляре для одной HTTP-сессии. Все HTTP-запросы в пределах времени жизни одной сессии будут иметь доступ к одному и тому же бину.
5.Application - создается в одном экземпляре для жизненного цикла ServletContext (ServletContext живет и функционирует в пределах процесса сервера и может получать информацию о своем окружении). Виден как атрибут ServletContext.

---

6.Websocket - создается в одном экземпляре для определенного сеанса WebSocket (тип протокола связи). Один и тот же бин возвращается всякий раз, когда к нему обращаются в течение всего сеанса WebSocket.
Виды бинов:

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

2.Session Bean – функциональный бин. У каждого Session Bean есть своя функция. Такие бины работают с другими объектам и бинами, а не со своими данными. Делится на две категории.

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

-Statefull Session Bean – хранит у себя внутри данные, которые использует при работе. Если мы вызываем методы этого бина, то в каждом следующем вызове он может использовать часть данных, переданных ему в предыдущих

3. 
   Чем бин отличается от POJO-класса?
   

POJO (англ. Plain Old Java Object) - простой Java-объект, не унаследованный от какого-то специфического объекта и не реализующий никаких служебных интерфейсов сверх тех, которые нужны для бизнес-модели.

Spring Bean — это объект, управляемый Spring. В частности, это объект, который создается, настраивается и иным образом управляется контейнером Spring Framework. Spring Bean определяются в файлах конфигурации Spring или при помощи @аннотаций, создаются контейнерами Spring, а затем внедряются в приложения.
Различия:

1. Все JavaBeans - POJO, но не все POJO являются JavaBeans.

2. Бины должны реализовывать интерфейс Serializable. Тем не менее, некоторые POJO, которые не реализуют интерфейс Serializable, называются POJO, потому что Serializable - маркерный интерфейс и не несет большой нагрузки.

3. Bean поля должны быть приватными. Это необходимо для обеспечения полного контроля над полями.

4. Bean имеют конструктор по умолчанию

5. К полям Bean обращаются только через геттеры-сеттеры.

4. 
   Что такое Inversion of Control и как Spring реализует этот принцип?
   

IoC (Inversion of Control) - инверсия управления. Это принцип в разработке, при котором управление объектами или частями программы передается контейнеру или фреймворку (Spring’y). Процессом выполнения кода/программы управляет фреймворк, мы передали ему контроль (тем самым “инверсируя управление”).

---

Программирование без фреймворков - наш код обращается к библиотекам, IoC - фреймворк обращается к нашему коду (используя абстракции и свое поведение, рефлексию)

Преимущества этой архитектуры:

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

Вместо ручного внедрения зависимостей, фреймворк забирает ответственность за это посредством контейнера, который отвечает за управление жизненным циклом объекта (бина): Spring создает объекты (бины), вызывает методы инициализации и конфигурирует объекты путем связывания их между собой. Конфигурирование контейнера осуществляется путём внедрения @аннотаций или XML-файлов.
Объекты могут быть получены одним из двух способов:

1. 
   Dependency Lookup (поиск зависимости) - вызывающий объект запрашивает у объекта-контейнера экземпляр объекта с определенным именем или определенного типа.
   
2. 
   Dependency Injection (внедрение зависимости) - контейнер передает экземпляры объектов по их имени другим объектам с помощью конструктора, свойства или фабричного метода (инициализация объекта через публичный статический метод, называемый фабричным методом).
   

5. 
   Для чего существует такое количество ApplicationContext?
   

ApplicationContext — это главный интерфейс в Spring-приложении, который предоставляет информацию о конфигурации приложения. Так же, как BeanFactory, ApplicationContext (наследуя BeanFactory и расширяя функционал для enterprise приложений) загружает бины, связывает и конфигурирует их определённым образом. Но, кроме этого, ApplicationContext обладает дополнительной функциональностью.

Это мапа!

ApplicationContext предоставляет:

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

Зачем так много - Чтобы можно было задавать разные способы конфигурирования.

• 
  FileSystemXmlApplicationContext - указываем полный путь к XML-файлу с конфигурацией бинов (для автономных приложений)
  
• 
  ClassPathXmlApplicationContext - XML-файл с конфигурацией бинов помещаем в CLASSPATH (для автономных приложений)
  
• 
  XmlWebApplicationContext - загружает XML-файл с метаданными бинов - (веб-приложения)
  
• 
  AnnotationConfigApplicationContext - для обычной Java-конфигурации, в качестве аргумента которому передается класс, либо список классов с аннотацией @Configuration, @Component и др.
  
• 
  WebApplicationContext - для веб-приложений;
  

---

ApplicationContext ctx = new FileSystemXmlApplicationContext("c:/bean_properties.xml");

6. 
   Как можно связать бины?
   

Связывание бинов или внедрение зависимостей происходит по следующему алгоритму:

1. Описание бинов:

• 
  полностью в .xml файле,
  
• 
  в java коде с использованием аннотаций (@Configuration + методы, помеченные аннотацией @Bean, которые возвращают бины)
  
• 
  полностью с помощью аннотаций (@Configuration + @ComponentScan + @Component)
  

2. Внедрение зависимостей (Dependency Injection), может происходить через конструктора (предпочтительно, при этом аннотация не нужна), через сеттеров, через поле над которыми ставиться аннотация @Autowire

над чем ставить autowire - хабр статья

7. 
   Что такое Dependency Injection?
   

Dependency Injection (внедрение зависимости) - набор паттернов и принципов разработки программного обеспечения, которые позволяют писать слабосвязанный код. Построением/внедрением зависимостей зависимостей занимается контейнер IoC Spring’a. При помощи DI объекты определяют свои зависимости (то есть другие объекты, с которыми они работают).
Всего есть 3 варианта внедрения: через конструктора, через сеттеров, через аннотацию над полем.

К достоинствам применения DI можно отнести:

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

Реализация DI в Spring основана на двух ключевых концепциях Java — компонентах JavaBean и интерфейсах. За счет применения DI объем кода, который необходим при проектировании приложения на основе интерфейсов, снижается почти до нуля. Кроме того, с помощью интерфейсов можно получить максимальную отдачу от DI, потому что бины могут использовать любую реализацию интерфейса для удовлетворения их зависимости.
К типам реализации внедрения зависимостей в Spring относят:

• 
  @Autowired DI - аннотация Spring, помечают конструктор, поле, сеттер-метод или метод конфигурации, сигнализируя, что им обязательно требуется внедрение зависимостей. Если в контейнере не будет обнаружен необходимый для вставки бин, то будет выброшено исключение, либо можно указать @Autowired (required = false), означающее, что внедрение зависимости в данном месте не обязательно.
  
• 
  Constructor DI - зависимости компонента предоставляются ему в его конструкторе. Рекомендуется как основной способ.
  
• 
  Setter DI - контейнер IoC внедряет зависимости через методы установки (сеттеры) в стиле JavaBean.
  

---

8. 
   Какие бины будут использоваться для настройки приложения?
   

• 
  @Configuration - перед классом означает, что класс может быть использован контейнером Spring IoC как конфигурационный класс для бинов.
  
• 
  @Bean - перед методом, информирует Spring о том, что возвращаемый данным методом объект должен быть зарегистрирован как бин
  
• 
  @ComponentScan("path") - задает путь, по которому спринг будет искать классы для создания бинов.
  
• 
  @EnableTransactionManagement - включает функцию управления транзакциями Spring на основе аннотаций (а нужно ли оно?)
  
  
  

9. 
   Как получить данные из файла «.property»?
   

1. 
   Указываем конфигурацию @PropertySource (classpath:application.properties"). Обращаясь к property.getProperty({ключ}) – вы получаете его значение.
   
2. 
   Для xml указываем
   
3. 
   @Value на параметрах конструктора
   

Указываемся@Value("${emp.name}"), при этом должен быть:
@Bean

public static PropertySourcesPlaceholderConfigurer configurer() {

return new PropertySourcesPlaceholderConfigurer();

}

4. 
   Класс Environment и его методы (например private Environment env; env.getProperty()), перед этим необходимо сообщить название файла.
   
5. 
   В SpringBoot заранее прописан файл application.properties
   

10. 
    Как запустить Спринг-приложение из-под сервера Tomcat?
    

1. 
   Добавить конфигурацию Tomcat
   
2. 
   Расширяем main-класс с помощью SpringBootServletInitializer.
   
3. 
   В pom.xml указываем
   war
   
   
4. 
   Сделать .jar файлы доступными (перенести в папку webapp/WEB-INF/lib)
   
5. 
   Добавляем зависимость spring-boot-starter-tomcat
   

// Или добавить tomacat через run - edit configurations.

11. 
    Что такое Artifacts?
    

Артефакты - в широком смысле это некие объекты создаваемые в ходе разработки ПО, например схемы классов, код, документация, инструкции, иконки, картинки и все что сопровождает процесс разработки.
В узком смысле – некая выходная сборка вашего проекта со всеми его зависимостями: библиотеками, плагинами, статическими ресурсами предназначенный для тестирования, деплоя. В общем случае их может быть несколько: .jar для десктопа и .war для веба. Для каждого артефакта можно определить правила сборки, развертывания, запуска и т.д.

12. 
    В чем отличие артефакта war от war exploded?
    

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

---

Смотрите также файлы

• Дугер Долума Эндокринная система Эпифиз.docx

• Кто были предки Славян.docx

• История развития разработки малахитовых руд и месорождений.docx

• Внедрение бережливого управления в образовательное пространство. Оптимизация системы сдачи школьной отчетности.docx

• Проблемы назначения и производства криминалистической экспертизы по уголовным делам.docx