Хочешь, хорошо работать пользуйся Спрингом. Хочешь, чтобы работало хорошо знай его кишки. Навигация
 Скачать 4.45 Mb.
|
|
В документе я не стал описывать такие языки как html (разметка, скелет веб страницы), css (стили, кожа страницы) и JavaScript (внутренние органы страницы), думаю, что при выполнении задач, вы сами с ними разобрались. | ||||||||||||||||||
| SPRING В НАЧАЛО ДОКУМЕНТА | ||||||||||||||||||
| 1. Что такое Spring? | ||||||||||||||||||
| Spring – это один из самых популярных фреймворков для создания веб-приложений на Java. Spring — это просто набор каких-то классов и интерфейсов, которые уже написаны за вас :) | ||||||||||||||||||
| 2. Что такое фреймворк и библиотека, отличие? | ||||||||||||||||||
| Фреймворк — это что-то похожее на библиотеку (возможно этот термин вам более знаком), но есть один момент. Грубо говоря, используя библиотеку, вы просто создаёте объекты классов, которые в ней есть, вызываете нужные вам методы, и таким образом получаете нужный вам результат. То есть, тут более императивный подход: вы чётко указываете в своей программе в какой конкретный момент надо создать какой объект, в какой момент вызвать конкретный метод, и т.д. С фреймворками дела обстоят слегка иначе. Вы просто пишете какие-то свои классы, прописываете там какую-то часть логики, а создаёт объекты ваших классов и вызывает методы за вас, уже сам фреймворк. Чаще всего, ваши классы имплементируют какие-то интерфейсы из фреймворка или наследуют какие-то классы из него, таким образом получая часть уже написанной за вас функциональности. | ||||||||||||||||||
| 3. Структура Spring? Его модули? Какая основная зависимость/модуль? | ||||||||||||||||||
| S  pring — это не один какой-то конкретный фреймворк. Это скорее общее название для целого ряда небольших фреймворков, каждый из которых выполняет какую-то свою работу.Как видно, у спринга модульная структура. Это позволяет подключать только те модули (зависимости), что нам нужны для нашего приложения и не подключать те, которыми мы заведомо не будем пользоваться. Вот основные модули (зависимости): 1) Основной модуль Core контейнер - предоставляет основной функционал Spring. Главным компонентом контейнера является BeanFactory - реализация паттерна Фабрика. BeanFactory позволяет разделить конфигурацию приложения и информацию о зависимостях от кода. 2) Spring context - конфигурационный файл, который предоставляет информация об окружающей среде для Spring. Сюда входят такие enterprise-сервисы, как JNDI, EJB, интернационализация, валидация и т.п. 3) Spring AOP - отвечает за интеграцию аспектно-ориентированного программирования во фреймворк. Spring AOP обеспечивает сервис управления транзакциями для Spring-приложения. 4) Spring DAO - абстрактный уровень Spring JDBC DAO предоставляет иерархию исключений и множество сообщений об ошибках для разных БД. Эта иерархия упрощает обработку исключений и значительно уменьшает количество кода, которое вам нужно было бы написать для таких операций, как, например, открытие и закрытие соединения. 5) Spring ORM - отвечает за интеграцию Spring и таких популярных ORM-фреймворков, как Hibernate, iBatis и JDO. 6) Spring Web module - отвечает за context web-приложений. 7) Spring MVC framework - реализация паттерна MVC для построения Web-приложений. | ||||||||||||||||||
| 4. Как работают шаблоны JDBC в Spring DAO? (На примере JdbcTemplate) | ||||||||||||||||||
| Когда нам приходится работать с простым JDBC, такие операции, как открытие/закрытие соединения с базой данных (далее – БД), обработка исключений и т.д. делают код крайне громоздким. Реализация JDBC в Spring Framework берёт на себя работу со многими низкоуровневыми операциями (открытие/закрытие соединений, выполнение SQL-запросов и т.д.). Благодаря этому при работе с БД в Spring Framework, нам необходимо только определить параметры соединения с БД и прописать SQL-запрос, остальную работу за нас выполняет Spring. JDBC в Spring имеет несколько классов (несколько подходов) для взаимодействия с БД. Наиболее распространённый из них – это класс JdbcTemplate, который управляет обработкой всех событий и связями с БД. Класс JdbcTemplate выполняет SQL-запросы, выполняет итерации по ResultSet и извлекает вызываемые значения, обновляет инструкции и вызовы процедур, “ловит” исключения и транслирует их в исключения, определённые в пакете org.springframwork.dao. Экземпляры класса JdbcTemplate являются потокозащищёнными. Это значит, что настроив единственный экземпляр класса JdbcTemplate, мы можем затем его использовать для нескольких объектов DAO. При использовании JdbcTemplate, чаще всего, он настраивается в конфигурационном файле Spring. После этого он внедряется как бин в классы DAO. | ||||||||||||||||||
| 5. Что такое инверсия управления (Inversion of Control) и как Spring реализует этот принцип? | ||||||||||||||||||
| Принцип Inversion of Control (IoC) гласит: программировать надо на интерфейсах, а не на их реализациях. Допустим, вы пишете приложение с текстовым интерфейсом. В своей функции Main вы запрашиваете пользовательский ввод, ожидаете от пользователя последовательности символов, вызываете подпрограммы для обработки полученных данных (может быть, даже в отдельных потоках), а функции общего характера запрашиваете у подключённых библиотек. Таким образом вся власть сконцентрирована в ваших руках, и написанный вами код полностью управляет потоком выполнения приложения. Но в один прекрасный день в кабинет входит босс и сообщает пренеприятнейшее известие — консоль больше не в моде, миром правят графические интерфейсы, а значит всё надо переделать. Будучи современным и гибким (речь не только о ваших занятиях йогой) программистом, вы сразу принимаетесь за внесение изменений. Для этого вы подключаете GUI-фреймворк и пишете код обработки событий. Если нажата вот эта кнопка, то надо сделать то-то и то-то. А если пользователь изменил свой выбор в выпадающем списке, то не обойтись без вот этого и этого. Всё идет хорошо, но тут вы понимаете, что раньше было как-то по-другому. А кто, собственно, вызывает эти обработчики событий, которые вы так усердно программируете? Кто вообще определяет, куда и когда нажал пользователь? Что вообще происходит? Где мои носки? GUI-фреймворк оказался явно хитрее, чем вы думали, и перехватил у вас управление потоком выполнения приложения. Это и есть Inversion of Control — очень абстрактный принцип, постулирующий факт задания потока выполнения некой внешней по отношению к вам сущностью. Например: Передача управления фреймворку. Понятие IoC тесно связано с понятием фреймворка. Это главная характеристика, отличающая его от другого способа оформления переиспользуемого кода — библиотеки, функции, которые вы просто вызываете из своей программы. Фреймворк же — это внешний каркас, предоставляющий заранее определенные точки расширения. В эти точки расширения вы и вставляете свой код, но, когда он будет вызван определяет именно фреймворк. То есть, тут уже не вы управляете процессом выполнения кода/программы, а фреймворк это делает за вас. Вы передали ему управление (инверсия управления). Подробнее тут! и ТУТ! | ||||||||||||||||||
| 6. Что такое IoC контейнер? Как его сконфигурировать? | ||||||||||||||||||
| Контейнер — это объект, реализующий интерфейс ApplicationContext. IoC контейнер создаёт объекты, связывает их вместе, настраивает и управляет ими от создания до момента уничтожения. IoC контейнер в Spring берёт заботу об инициализации объектов на себя. Нам больше не нужно самостоятельно писать фабрики для каждого интерфейса, которые возвращали бы, тот или иной объект. Фабрики уже встроены в контейнеры. И, кроме того, контейнер берёт на себя управление жизненным циклом каждого бина. Для управления компонентами, из которых состоит приложение, Spring Container использует Внедрение Зависимостей (DI). Эти объекты называются Spring Beans. S  pring Container получает инструкции какие объекты инстанцировать и как их конфигурировать через метаданные.Метаданные могут быть получены 3 способами: – XML (актуальна только для старых проектов.) – Аннотации Java (используется чаще всего) – Java код В IoC существуют 4 аннотации, которыми помечаются классы: @Component, @Service, @Controller, @Repository. Java POJO классы поступают в Spring Container, который на основании инструкций, полученных через метаданные, выдаёт приложение, готовое к использованию. | ||||||||||||||||||
| 7. Жизненный цикл контейнера? | ||||||||||||||||||
| - Контейнер создается при запуске приложения - Контейнер считывает конфигурационные данные - Из конфигурационных данных создается описание бинов - BeanFactoryPostProcessors обрабатывают описание бина - Контейнер создает бины используя их описание - Бины инициализируются — значения свойств и зависимости внедряются в бин - BeanPostProcessor запускают методы обратного вызова(callback methods) - Приложение запущено и работает - Инициализируется закрытие приложения - Контейнер закрывается - Вызываются callback methods | ||||||||||||||||||
| 8. Сколько IoC контейнеров существует в Spring? (2 контейнера) | ||||||||||||||||||
| 1. Spring BeanFactory Container; 2. Spring ApplicationContext Container; | ||||||||||||||||||
| 9. В чём разница между IoC контейнерами BeanFactory и ApplicationContext? | ||||||||||||||||||
| IoC контейнер —Вместо ручного внедрения зависимостей, забирает ответственность за это на себя. BeanFactory — это базовая, простая версия IoC контейнера обеспечивающая базовую поддержку DI. Основан на интерфейсе org.springframework.beans.factory.BeanFactory. BeanFactory обычно используется тогда, когда ресурсы ограничены (мобильные устройства). Поэтому, если ресурсы не сильно ограничены, то лучше использовать ApplicationContext. ApplicationContext — это улучшенная версия IoC контейнера, обёртка над BeanFactory. Является более сложным и продвинутым Spring Container-ом. Так же, как BeanFactory, ApplicationContext загружает бины, связывает их вместе и конфигурирует их определённым образом. Но, кроме этого, ApplicationContext обладает дополнительной функциональностью: AOP, транзакции, безопасность, распознание текстовых сообщений из файлов настройки и отображение событий. Этот контейнер определяется интерфейсом org.springframework.context.ApplicationContext. | ||||||||||||||||||
| 10. Что такое акроним SOLID? Расшифровка, значение. | ||||||||||||||||||
| - S: Single Responsibility Principle (Принцип единственной ответственности). Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой. - O: Open-Closed Principle (Принцип открытости-закрытости). Программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации. - L: Liskov Substitution Principle (Принцип подстановки Барбары Лисков). Цель этого принципа заключаются в том, чтобы классы-наследники могли бы использоваться вместо родительских классов, от которых они образованы, не нарушая работу программы. Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается. - I: Interface Segregation Principle (Принцип разделения интерфейса). Создавайте узкоспециализированные интерфейсы, предназначенные для конкретного клиента. Клиенты не должны зависеть от интерфейсов, которые они не используют. Этот принцип направлен на устранение недостатков, связанных с реализацией больших интерфейсов. - D: Dependency Inversion Principle (Принцип инверсии зависимостей). Объектом зависимости должна быть абстракция, а не что-то конкретное. Почитать | ||||||||||||||||||
| 11. Что такое инверсия зависимости (Dependency Inversion)? | ||||||||||||||||||
| Это та самая буква D в аббревиатуре SOLID — принцип, говорящий о том, что: 1. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций; 2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. П   роблема здесь заключается в том, что класс Foo зависит от конкретного класса Bar. По той или иной причине — в целях расширяемости, переиспользуемости или тестируемости ради — может встать задача их разделить. Согласно принципу инверсии зависимости для этого следует ввести между ними промежуточную абстракцию.Г  де же здесь, инверсия? Основополагающая идея, без понимания которой невозможно ответить на этот вопрос, заключается в том, что интерфейсы принадлежат не своим реализациям, а использующим их клиентам. Имя интерфейса IBar вводит в заблуждение и заставляет рассматривать связку IBar + Bar как единое целое. В то же время истинным владельцем IBar является класс Foo, и если принять это во внимание, то направление связи между Foo и Bar действительно обратится вспять. | ||||||||||||||||||
| 12. Что такое внедрение зависимости (Dependency Injection)? | ||||||||||||||||||
| Н  юанс заключается в том, что класс Foo теперь совершенно не зависит от класса Bar, но по-прежнему управляет его инстантинацией. Как мы уже знаем, избежать этого можно инвертировав поток управления, т.е. передав оное управление в руки некоего внешнего механизма. Dependency Injection и является таким механизмом, реализуемым в виде фреймворков под названием IoC-контейнеры:Существует два типа DI: через сэттер и через конструктор. Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами. Таким образом, при применении DI, ваш код становится чище, проще, его становится легче понять и тестировать. Согласно паттерну DI, создание объектов для зависимостей переходит на фабрику или отдаётся третьей стороне. Это означает, что мы можем сосредоточиться на использовании этих объектов вместо их создания. Преимущества DI - Уменьшает связь между частями приложения, Облегчает тестирование, Упрощает архитектуру приложения, Уменьшает шаблонный код, Стандартизирует разработку приложения. | ||||||||||||||||||
| 13. Отличия Dependency Inversion, Dependency Injection и Inversion of Control? | ||||||||||||||||||
| - Мы используем Dependency Inversion, чтобы разделить модули абстракцией (то есть не делаем жёстких связей между нашими модулями/классами, где один класс напрямую завязан на другой). - Dependency Injection, чтобы избавиться от инстантинации вручную (это когда объекты котиков создаёте не вы в main-е и потом передаёте их в свои методы, а за вас их создаёт спринг, а вы ему просто говорите что-то типа "хочу сюда получить котика" и он вам его передаёт в ваш метод). - А реализуем всё это посредством фреймворка, построенного по принципу Inversion of Control. И ничто из этого не является синонимами. | ||||||||||||||||||
| 14. Объясните работу интерфейса BeanFactory в Spring? | ||||||||||||||||||
| BeanFactory — это реализация паттерна Фабрика, его функциональность покрывает создание бинов. Так как эта фабрика знает о многих объектах приложения, то она может создавать связи между объектами на этапе создания экземпляра. Существует несколько реализаций BeanFactory, самая используемая - "org.springframework.beans.factory.xml.XmlBeanFactory". Она загружает бины на основе конфигурационного XML-файла. Чтобы создать XmlBeanFactory передайте конструктору InputStream, например:  П  осле этой строки фабрика знает о бинах, но их экземпляры ещё не созданы. Чтобы инстанцировать бин нужно вызвать метод getBean(). Например:Подробнее тут! | ||||||||||||||||||
| 15. Почему лучше использовать ApplicationContext а не BeanFactory? | ||||||||||||||||||
| Поскольку ApplicationContext включает в себя все функциональные возможности BeanFactory, рекомендуется использовать его, за исключением нескольких ограниченных ситуаций, таких как в апплете , где потребление памяти может быть критическим. Однако для большинства «типичных» корпоративных приложений и систем ApplicationContext — это то, что вы захотите использовать. Версии Spring 2.0 и выше интенсивно используют точку расширения BeanPostProcessor (для выполнения проксирования и т.п.), если вы используете просто BeanFactory тогда поддержка, такая как транзакции и АОП, не вступит в силу (по крайней мере, без некоторых дополнительных шагов с вашей стороны), что может сбивать с толку, потому что на самом деле с конфигурацией всё в порядке.
|