Загальна інформація про Spring



Скачати 139.95 Kb.
Дата конвертації23.10.2017
Розмір139.95 Kb.
ТипРеферат

Національний університет “Києво-Могилянська академія”

Реферат

на тему
Spring Framework”
студентки МП-1

Інформаційні управляючі

системи та технології

Чесановської Олени


Київ

2007

План


План 2

Загальна інформація про Spring 3

Чим займається і що пропонує Spring? 4

Архітектура та основні компоненти Spring 6

IoC контейнер 6

AOP 9

Додаткові можливості 12

JDBC 13


ІнтерналізацІя (i18n) і конфігурація 14

Events 15



Переваги Spring 16

Висновок 19

Використані джерела 20

Загальна інформація про Spring


Spring – рівневий фреймворк для розробки Java/J2EE додатків, оснований на коді, опублікованому в “Expert One-on-One J2EE Design and Development” Родом Джонсоном.

Spring включає:



  • Найповніший легкий контейнер, який забезпечує централізовану, автоматизовану конфігурацію та з’єднання об’єктів. Контейнер може з наборів вільно з’єднаних компонентів складної системи (POJOs) скласти стійку та прозору форму. Контейнер забезпечує швидкість, забезпечує тестованість та масштабованість додатку шляхом можливості розробки та тестування компонентів ізольовано з подальшою масштабованістю для використання у будь-якому середовищі (J2SE чи J2EE).

  • Спільний абстрактний рівень для управління трансакціями, який дозволяє змінювати менеджерів трансакцій та розподіляти трансакції, не маючи справи з низькорівневими проблемами.

  • Включено стратегії JTA та єдиного джерела даних JDBC DataSource. На противагу простим JTA чи EJB CMT, підтримка трансакцій в Spring не прив’язана до середовища J2EE.

  • Абстрактний рівень JDBC, який пропонує чітку ієрархію виключень, спрощує обробку помилок, і значно зменшує об’єм необхідного коду. Тепер вже не потрібно писати ще один блок для того, щоб знову використати JDBC. JDBC-орієнтовані виключення реалізовують Spring-ову ієрархію виключень DAO.

  • Інтеграція з Toplink, Hibernate, JDO, та iBATIS SQL Maps: в якості сховища ресурсів, підтримки реалізації DAO та стратегій трансакцій. Першокласна підтримка Hibernate з безліччю зручних функцій IoC, що стосуються багатьох типових інтеграційних функцій Hibernate.

  • Функціональність AOP, повністю інтегрована в менеджмент конфігурацій Spring-а. Можна AOP-enable будь-який об’єкт керований Spring-ом, додавши такі аспекти як декларативне управління трансакціями. З Spring ви можете мати декларативне управління трансакціями навіть без EJB... чи без JTA, якщо ви використовуєте єдину базу даних в Tomcat чи іншому веб сервері без підтримки JTA.

  • Гнучкий MVC фреймворк веб додатків, побудований на основній функціональності Spring. Цей фреймворк високо конфігурований через інтерфейси і забезпечує численні технології як JSP, Velocity, Tiles, iText, та POI. Зауважте, що проміжний рівень Spring може бути легко з’єднаний з веб рівнем на будь-якому іншому MVC веб фреймворку, наприклад, Struts, WebWork, чи Tapestry.


Використовувати всю функціональність Spring можна на будь-якому J2EE сервері, і більшість – в некерованих середовищах. Spring робить фокус на бізнес об’єктах та об’єктах доступу до даних повторно використання, які не прив’язані до специфічних сервісів J2EE. Такі об’єкти можуть бути багаторазово використані в середовищах J2EE (веб або EJB), автономних додатках, тестових середовищах, і т.п. без будь-яких перешкод.

Spring-ова рівнева архітектура дозволяє достатню гнучкість. Вся її функціональність побудована на нижчих рівнях. Тож, ви можете, наприклад, використовувати управління конфігурацією JavaBeans без використання фреймворку MVC чи підтримки AOP. Але якщо вив використовуватимете веб фреймворк MVC чи підтримку AOP, ви побачити, що вони побудовані на конфігураційному фреймворку, тож ви можете без проблем застосовувати ваші знання про нього.



Чим займається і що пропонує Spring?


Spring забезпечує значну функціональність. Яка ж місія Spring?

Спочатку варто визначити, що покриває Spring. Хоча горизонт Spring досить широкий, треба для себе зрозуміти, до чого Spring має справу чи не має.

Головна мета Spring – полегшити використання J2EE та пропагувати хорошу практику програмування. Він реалізує це, забезпечуючи модель програмування на основі POJO, яка застосовна у значній кількості середовищ.

Spring не перевинаходить колесо. Тому в Spring не знайти логуючих пакетів, пулів з’єднань, координатора розподілених трансакцій. Всі ці речі надаються проектами open source (такими як Commons Logging або Commons DBCP) або завдяки серверу застосувань. З тієї самої причини, O/R mapping рівень теж не забезпечується. Для цього хорошим вирішенням буде TopLink, Hibernate та JDO.

Spring не має на меті полегшити використання наявних технологій. Наприклад, хоча координація низькорівневих трансакцій не охоплюється спектром, абстрактний рівень над JTA чи будь-якою іншою транзакційною стратегією забезпечується.

Spring відкрито не змагається з іншими open source до того часу, поки немає можливості запропонувати щось нове. В деяких сферах, таких як IoC контейнер та AOP фреймворк, Spring має пряму конкуренцію, але Spring був піонером в цих сферах.

Spring має переваги від внутрішньої consistency. Всі розробники співають гімн з одного листка, тобто фундаментальні ідеї черпаються з Expert One-on-One J2EE Design and Developmen. Центральні концепції, як наприклад IoC, використовуються в багатьох місцях.

Spring – мобільна між серверами застосувань. Звичайно, мобільність – це завжди певні труднощі і небезпека, але творці Spring намагаються уникати будь-що платформенно-залежне чи нестандартне з погляду розробника, та надають підтримку на WebLogic, Tomcat, Resin, JBoss, Jetty, Geronimo, WebSphere та інших серверах застосування. Підхід з POJO надає можливість скористатись перевагами рис, специфічних для певного середовища, не жертвуючи при цьому мобільністю.


Архітектура та основні компоненти Spring

Архітектура Spring представлена наступною схемою



Ядро

IoC контейнер


В основі Spring лежить паттерн Inversion of control. Основна ідея цього паттерна полягає в викоріненні залежності компонентів чи класів застосування від конкретних реалізацій допоміжних інтерфейсів і делегуванні повноважень по управлінню створенням необхідних реалізацій IoC контейнеру. Розглянемо UML діаграму.

Мал. 1


IoC контейнер відповідає за створення необхідної реалізації Product для Consumer. При використанні класу Consumer в інших проектах ми зможемо замінити реалізацію интерфейсу Product на більш підходящу, не вносячи змін в код.
Основні переваги IoC контейнерів:

  1. Управління залежностями

  2. Спрощення повторного використання класів чи компонентів

  3. Спрощення unit-тестування

  4. Більш "чистий" код (Класи більше не займаються ініціалізацією допоміжних об’єктів. Не варто, звісно "перегинати палку", керуюи створенням абсолютно всіх об’єктів через IoC. В IoC контейнер найкраще виносити ті інтерфейси, реалізація яких може бути змінена в поточному проекті чи в майбутніх проектах.)

Паттерн IoC не єдиний, що дозволяє позбавитись від залежності від реалізації. Альтернативою IoC є добре відомі шаблони ServiceLocator/Factory.

Мал. 3. Шаблон ServiceLocator

Даний підхід вносить залежність коду від ServiceLocator, що призводить до меншої гнучкості. Основні недоліки шаблону ServiceLocator:


  1. Якщо в одному проекті в різних випадках необхідні різні реалізації Product, доведеться або міняти код виклику ServiceLocator в усіх використовуваних місцях, вказуючи додаткові параметри, або міняти сам ServiceLocator. Обидва варіанти призводять до "засмічування" коду, внесенню додаткових умов і параметрів, які ускладнюють код і його повторне використання.

  2. При використанні коду в інших проектах

  • (ServiceLocator розповсюджується разом з кодом) У випадку, коли для отримання потрібної реалізації Product необхідні додаткові параметри, доведеться вносити зміни в наданий ServiceLocator. Це ще призводить до існування в системі декількох ServiceLocator, кожен з яких необхідно по-своєму налаштовувати, що ускладнює супровід.

  • (ServiceLocator не розповсюджується с кодом) В цьому випадку доведеться міняти виклик ServiceLocator на використовуваний в даній системі. Введення спільного інтерфейсу також не вирішує проблеми.

Найпоширеніший спосіб вказання залежностей це XML файли конфігурації (applicationContext.xml).

Spring – це значно більше, ніж просто IoC контейнер. Framework спрощує розробку J2EE проектів, реалізуючи низькорівневі і найчастіше використовувані частини корпоративного застосування.


AOP

Одним з ключових компонентів Spring є AOP framework. Навіть не використовуючи AOP напряму всі, швидше за все, зіштовхнуться з ним непрямо.


Основні задачі, які вирішуються за допомогою AOP в Spring:

  1. Декларативне управління транзакціями.

  2. Організація пулів об’єктів.

  3. Написання власних аспектів.

Найзручніший і найгнучкіший спосіб управління транзакціями це декларативне управління транзакціями. Якщо хтось раніше працював з EJB CMT, то він чудово уявляє, що це таке. Декларативне управління транзакціями позбавляє код від залежності від фреймворка чи конкретного механізму управління транзакціями.
Конфігураційний файл (applicationContext.xml) виглядає наступним чином:


>



PROPAGATION_REQUIRED,readOnly

PROPAGATION_REQUIRED

Об’єкт myService - це вже транзакційний MyBusinessObject, доступ до нього здійснюється через Proxy (TransactionProxyFactoryBean), який і управляє транзакціями. Для користувача не буде ниякої різниці, чи то робота з Proxy, чи то робота з MyBusinessObject напряму. Є і інший спосіб опису транзакційної конфігурації, через BeanNameAutoProxyCreator. Даний спосіб дозволяє скоротити розмір конфігураційного файлу.

Організація пулів об’єктів застосовується і до EJB. Контейнер підтримує пул stateless session EJB, при виклику методу об’єкт звільняється з пула. При використанні Spring, пул об’єктів може підтримуватись для будь-яких POJO (Plain Old Java Object). Приклад конфігураційного файлу:


singleton="false"/>


>

25





>


AOP допомагає позбавитись від дублювання коду. Java - це об’єктно-орієнтована мова, яка дозволяє створювати ієрархії взаємозв’язаних об’єктів. Але як бути, якщо один і той самий код використовується в різних ієрархіях об’єктів?

Будь-яке застосування можна розглядати з двох позицій: з точки зору функціональності окремих класів (core concerns) і функціонала, який охоплює все застосування (crosscutting concerns). Модулі, які керують crosscutting concerns, називаються аспектами. В Spring аспекти реалізуються через Advisors і Interceptors.
Аспекти можуть вирішувати наступні задачі: логування, кешування, управління безпекою, транзакції і т.д. Введення додаткового шару інтерцепторів размежовує відповідальність між основним кодом і допоміжними задачами. В результаті спрощується супроводження коду і його повторне використання. Інтерцептори конфігуруються незалежно, вони моуть використовуватись в інших проектах, в свою чергу об’єкти можуть конфігуруватись з різними інтерцепторами.
В якості прикладу візьмемо задачу - визначення часу виконання методів. Це може бути корисно для виявлення вузьких місць, як в час тестування, так і на production при реальній кількості користувачів на реальних даних.


public class PerformanceInterceptor implements MethodInterceptor {

private static Logger log = Logger.getLogger(PerformanceInterceptor.class);
public Object invoke(MethodInvocation methodInvocation) throws Throwable {

Method method = methodInvocation.getMethod();
log.info("========= Start Performance log =============");

log.info("1. executing method: " + method.getName());


long startTime = System.currentTimeMillis();

Object result = methodInvocation.proceed();

long endTime = System.currentTimeMillis();
log.info("2. time: " + (endTime - startTime) + " ms");

log.info("========= End Performance log =============");


return result;

}

}


Зверніть увагу на інтерфейс org.aopalliance.intercept.MethodInterceptor. Це інтерфейс AOP Alliance. Відповідно такі інтерцептори є переносними в інші AOP frameworks. В Spring є свої власні інтерфейси інтерцепторів, призначені для різних випадків.


MethodInterceptor є найбільш повним контролем над процесом виконання. Для нашої задачі підходить саме цей інтерфейс. В рядку 12 відбувається виклик наступного інтерцептора в ланцюжку, або методу основного об’єкта. Варто зазначити, що для того, щоб PerformanceInterceptor надавав найточнішу інформацію про час виконання методу, він має бути останнім в ланцюжку.
Тепер залишилось тільки змінити конфігураційний файл.

/>

/>

>



performanceInterceptor







Додаткові можливості

Як вже було сказано раніше, Spring крім IoC контейнера включає в себе безліч класів, які реалізують найбільш необхідний функціонал J2EE застосувань. Spring суттєво спрощує роботу з JDBC, ORM frameworks, EJB, Web services. Framework реалізує більш високий рівень абстракції управління розсилкою пошти, кэшуванням, виконанням задач за розкладом. Крім цього Spring включає в себе ще і Web framework.


Малоймовірно, що в розроблюваному застосуванні будуть використовуватись всі можливості Spring. Тому можна включати в застосування тільки ті jar-архіви, класи котрих використовуються. Spring групує класи в jar по пакетах: spring-aop.jar, spring-beans.jar і т.д. Можна включити один jar з усіма класами - spring.jar.

Далі будуть описані деякі з можливостей Spring Framework.

JDBC


Розглянемо приклад.


public class SimpleDAO extends JdbcDaoSupport {

// SqlRowSet это disconnected java.sql.ResultSet



public SqlRowSet getUserRowSet(String id) {

return getJdbcTemplate().queryForRowSet(

"select name, email from user where id = ?",



new Object[] {id});

}

public int getMaxAmount() {



return getJdbcTemplate().queryForInt("select max(amount) from payments");

}

// Результат запроса "оборачивается" в бин User



public List getUsersByName(String username) {

return getJdbcTemplate().query(

"select * from user where username = ?",



new Object[] { username },

new RowMapper() {

public Object mapRow(ResultSet resultSet, int i)

throws SQLException {

User user = new User();

user.setId(resultSet.getInt(1));

user.setName(resultSet.getString(2));



return user;

}

});



}}

Більше не потрібно писати громіздкі конструкції try {..} catch (..) finally {..}, керувати з’єднаннями, транзакціями. Прості запити взагалі вміщуються в один рядок.


ІнтерналізацІя (i18n) і конфігурація

Spring включає класи й інтерфейси, призначені для інтерналізації застосування. Всі повідомлення зберігаються в properties файлах. Один properties файл відповідає одній мові. Для того, щоб отримати доступ до цих повідомлень, в applicationContext.xml необхідно додати messageSource бін. Ім’я messageSource є обов’язковим. Spring підтримує ієрархічні повідомлення.



>



springfundamentals.i18n.messages

springfundamentals.i18n.formats



В інтерфейсі ApplicationContext (основний інтерфейс, який визначає конфігурацію застосування) є відповідні методи getMessage(MessageSourceResolvable resolvable, Locale locale), getMessage(String code, Object[] args, Locale locale), getMessage(String code, Object[] args, String defaultMessage, Locale locale). Приклад використання:



messages_en.properties

======================

mesg=test message parameter: {0}
...
ApplicationContext context = ...

String message = context.getMessage(

"mesg",

new Object[] {"paramName"} ,



"default message",

Locale.US));


Всі конфігураційні параметри застосування зручно зберігати в одному чи декількох properties файлах. До них можна буде звертатись прямо з applicationContext.xml. Для цього в applicationContext.xml необхідно додати бін.



>



Тоді до параметрів можна буде звертатись наступним чином.



>


Де jdbc.jndiName - конфігураційний параметр в WEB-INF/config.properties.


Events


Обробка подій в Spring здійснюється через клас ApplicationEvent та інтерфейс ApplicationListener. При настанні події нотифікуються всі об’єкти, які реалізують інтерфейс ApplicationListener.

Розглянемо приклад.



public class EventPublisher implements ApplicationContextAware {

private ApplicationContext context;

public void setApplicationContext(ApplicationContext applicationContext)

throws BeansException {

this.context = applicationContext;

}

public void go() {

context.publishEvent(new ApplicationEvent("event") {



public long getTimestamp() {

return super.getTimestamp();

}

});



}

}

public class EventListener implements ApplicationListener {



public void onApplicationEvent(ApplicationEvent event) {

System.out.println("Event: " + event.getSource());



}

}



Виклик context.publishEvent() відбувається в синхронному режимі. Всі ApplicationListener виконуються в тому ж транзакційному контексті, що й EventPublisher.

Переваги Spring


За Родом Джонсоном Spring унікальний з декількох причин:

  • Він торкається багатьох сфер, яких інші популярні фреймворки не чіпають. Spring фокусується на забезпеченні можливості управління бізнес об’єктами.

  • Spring одночасно і рівневий, і модульний. Spring має рівневу архітектуру, що означає, що ви можете використовувати будь-яку її частину ізольовано, але все ж таки її структура внутрішньо послідовна. Ви можете використовувати Spring лише для спрощення використання JDBC, наприклад, або для управління всіма вашими бізнес об’єктами. До того ж, легко поступово впроваджувати Spring в інші готові проекти.

  • Spring спроектований з основи, для того, щоб допомогти вам писати код, який легко тестувати. Spring – ідеальний фреймворк test driven проектів.

  • Spring – інтеграційна технологія, яка набуває все більшої популярності, тому що її роль визнана кількома великими vendors.

Отже, Spring – потенційний one-stop магазин, який торкається більшості моментів інфраструктура типових додатків.

Архітектурні переваги Spring:

  • Spring може ефективно організувати об’єкти проміжного рівня, незалежно від того, чи вирішите ви використовувати EJB чи ні. Spring дбає про “склепання”, яке б залишилось на вашу долю, коли б ви використовували Struts чи інші фреймворки, залежних від певних J2EE APIs. А так як це, мабуть, найцінніше в проміжному рівні, Spring-ові сервіси управління конфігурацією можуть бути використані в будь-якому архітектурному рівні, в будь-якому runtime середовищі.

  • Spring може виключити неконтрольоване розмноження синглтонів, які спостерігаються в багатьох проектах. Насправді, це велика проблема, яка погано впливає на тестованість і об’єктну орієнтацію.

  • Spring може виключити необхідність в використанні різних форматів файлів для користувацьких властивостей, підтримуючи конфігурацію в несуперечливому стані для всіх застосувань і проектів. Вам траплялось цікавитись, які магічні ключі властивостей чи системні властивості необхідні конкретному класу, ф лізти за цими відомостями в Javadoc чи навіть вихідний код? В Spring досить подивитись у властивості JavaBean цього класу. Досягти такого спрощення допомагає використання Inversion of Control (інверсія керування, див. нижче).

  • Spring сприяє хорошому програмуванню, зменшуючи вартість програмування до інтерфейсів, замість класів, практично до нуля.

  • Spring спроектований так, щоб застосування, створені з його допомогою, залежали від найменшого можливого числа його API. Більшість бізнес-об’єктів в Spring-застосуваннях ніяк не залежать від Spring.

  • Для застосувань, створених за допомогою Spring, дуже просто проводити юніт-тестування.




  • Spring може зробити вибір EJB питанням реалізації, а не вирішуючим фактором архітектури застосування. Ви можете вирішити реалізовувати бізнес-інтерфейси як POJO (Plain Old Java Object, тобто прості об’єкти, а не Java Beans і т.п.) чи локальні EJB, ніяк не впливаючи цим на викликаний код.

  • Spring допомагає вирішити багато проблем, не втягуючи в це EJB. Spring може надати альтернативу EJB, застосовну для багатьох Web-застосувань. Наприклад, Spring може використовувати АОП для декларативного управління транзакціями без використання EJB-контейнера, і навіть без реалізації JTA, якщо обмежитись використанням одної БД.

  • Spring надає середовище доступу до даних з використанням JDBC чи таких ORM-продуктів, як Hibernate.

  • Spring надає стійку, просту модель програмування, перетворюючи її в ідеальний архітектурний "клей". Це можна простежити в підході Spring до JDBC, JMS, JavaMail, JNDI та багатьох інших важливих API.



Висновок

До основних переваг Spring відносяться: простота; зручність тестування; використання Spring позитивно відображається на дизайні застосування і простоті коду.


В Spring реалізовано багато, без чого не обходиться практично будь-яке Java застосування. Перед Тим, як щось винаходити щось своє, варто подивитись, може, це вже є в Spring.

Використані джерела





  1. http://springframework.org

  2. http://www.onjava.com/pub/a/onjava/2005/05/11/spring.html

  3. http://lib.juga.ru/article/articleview/216/1/3/

  4. http://www.optim.su/cs/2004/3/spring/spring.asp

  5. http://www.intuit.ru/department/se/compprog/15/4.html


Поділіться з Вашими друзьями:


База даних захищена авторським правом ©wishenko.org 2017
звернутися до адміністрації

    Головна сторінка