Главная » Spring » Свобода использования POJO

0

Те, кто имеет опыт достаточно продолжительной разработки на языке Java, вероятно, видели (и даже могли использовать) фрейм- ворки, вынуждающие расширять свои классы или предусматривать реализацию своих интерфейсов. Классическим примером являют- ся сеансовые компоненты эры EJB 2. Как показано в простейшем примере HelloWorldBean, спецификация EJB 2 предъявляет достаточно сложные требования:

Листинг 1.1. Спецификация EJB 2.1 вынуждает реализовывать ненужные методы

package  com.habuma.ejb.session;

import  javax.ejb.SessionBean; import   javax.ejb.SessionContext;

public class HelloWorldBean implements SessionBean { // Зачем все эти методы public  void  ejbActivate()  {

}

public void ejbPassivate() {

}

public  void  ejbRemove()  {

}

public  void  setSessionContext(SessionContext  ctx)  {

}

public String sayHello()  {     // Основная логика компонента  EJB return  "Hello  World";

}

public  void  ejbCreate()  {

Интерфейс SessionBean обеспечивает возможность управления жизненным циклом компонента EJB за счет реализации различ- ных методов обратного вызова (имена этих методов начинаются с последовательности символов ejb). Или, говоря другими слова- ми, интерфейс SessionBean вынуждает вторгаться в жизненный цикл компонента EJB, даже если в этом нет необходимости. Масса про- граммного кода в примере HelloWorldBean нужна только ради удов- летворения нужд фреймворка. В результате возникает вопрос: кто для кого работает?

Однако спецификация EJB 2 не единственная в своей насиль- ственности. Другие популярные фреймворки, такие как ранние версии Struts, WebWork и Tapestry, накладывали свой отпечаток на иначе простые Java-классы. Эти тяжеловесные фреймворки вы- нуждали разработчиков создавать классы, захламленные ненужным программным кодом, часто сложные в тестировании.

Фреймворк Spring не вынуждает (насколько это возможно) за- хламлять приложения программным кодом для поддержки своего API. Он практически никогда не заставляет обеспечивать реализа- цию своих интерфейсов или наследовать свои классы. Напротив, в приложениях, основанных на фреймворке Spring, классы часто вообще не имеют никаких признаков, по которым можно было бы судить, что они используются фреймворком. В худшем случае класс может быть аннотирован одной из аннотаций Spring, но во всех остальных отношениях он будет обычным объектом POJO.

Для иллюстрации класс HelloWorldBean, представленный в листин- ге 1.1, можно преобразовать в компонент, управляемый фреймвор- ком Spring, как показано в листинге 1.2.

Листинг 1.2. Фреймворк Spring не выдвигает необоснованных требований к классу HelloWorldBean

package com.habuma.spring;

public class HelloWorldBean {

public  String  sayHello()  {                                // Это  все,  что  необходимо return   "Hello   World";

}

}

Так лучше? Исчезли все ненужные методы управления жизнен- ным циклом. Класс HelloWorldBean не реализует, не наследует и не

импортирует ничего из Spring API. Класс HelloWorldBean мал, краток и во всех смыслах является простым Java-объектом.

Несмотря на свою простоту, простые Java-объекты могут об- ладать большими возможностями. Одним из механизмов Spring, увеличивающих мощь простых объектов, является их объединение с помощью внедрения зависимостей. Рассмотрим, как внедрение за- висимостей помогает сохранить прикладные объекты независимыми друг от друга.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии