Содержание


Groovy и Spring

Oсновы интеграции

Узнайте, как использование Groovy может повысить гибкость приложений на основе Spring

Comments

Серия контента:

Этот контент является частью # из серии # статей: Groovy и Spring

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Groovy и Spring

Следите за выходом новых статей этой серии.

В Spring 2.0 появилась возможность интеграции динамических языков в приложения на основе Spring, причем стандартным образом поддерживаются Groovy, JRuby и BeanShell. Это означает, что компоненты вашего приложения, написанные на Groovy, JRuby или любом другом поддерживаемом языке (в том числе, разумеется, на Java™) могут быть легко интегрированы в приложение на основе Spring. При этом интеграция будет выполнена совершенно прозрачно для других компонентов, которым необязательно знать о деталях реализации отдельных классов Java Bean.

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

Поддержка динамических языков в Spring

Благодаря поддержке динамических языков Spring превратился из инфраструктуры для создания Java-приложений в платформу для создания приложения для JVM. Теперь Spring упрощает разработку не только приложений на Java, но и программ для JVM в целом, позволяя сочетать компоненты, написанные как на статически, так и на динамически типизированных языках, в составе единой иерархической архитектуры. Если у вас есть опыт работы со Spring, то у вас не должно возникнуть проблем с поддержкой динамических языков; вы по-прежнему сможете использовать такие знакомые возможности Spring, как инверсия управления (inversion of control - IoC), внедрение зависимостей (dependency injection), аспектно-ориентированное программирование (aspect-oriented programming - AOP), декларативное разграничение транзакций (declarative transaction demarcation), интеграция с инфраструктурами Web и доступом к данным, а также удаленные вызовы, работая при этом с таким гибким, динамическом языком как Groovy.

Интеграция с динамическими языками в Spring реализуется через интерфейсы ScriptFactory и ScriptSource. Интерфейс ScriptFactory определяет механизм конфигурирования и создания в Spring объектов Java Bean, написанных на скриптовых языках. В теории может поддерживаться любой язык для JVM, поскольку можно добавить собственную реализацию этого интерфейса для нужного языка. Интерфейс ScriptSource определяет, каким образом будет осуществляться доступ к исходному коду на скриптовом языке из Spring (например, через файловую систему или по URL). В случае Groovy интеграция осуществляется при помощи класса GroovyScriptFactory, реализующего ScriptFactory.

Почему Groovy?

В соответствием с описанием на официальном сайте, Groovy - это "гибкий динамический язык для среды JVM", который "будучи основанным на Java, сочетает его преимущества с достоинствами таких языков как Python, Ruby и Smalltalk", в частности динамической типизацией, замыканиями и поддержкой метапрограммирования (см. Ресурсы). Groovy представляет собой полнофункциональный объектно-ориентированный язык программирования, который можно использовать как в этом качестве, так и для написания скриптов. Лично мне нравится взгляд на Groovy как язык, обладающий всеми возможностями Java кроме тех, которые вам не хочется задействовать, а также поддерживающий замыкания и другие функции, являющиеся стандартными для динамических языков.

Groovy является весьма удачным выбором для использования вместе со Spring, поскольку он специально проектировался для JVM и с учетом тесной интеграции с ней, обеспечивающей простое взаимодействие с кодом на Java. Кроме того, его синтаксис напоминает Java и, следовательно, прост для освоения Java-разработчиками.

Теперь можно переходить к рассмотрению вопросов интеграции кода на Groovy в приложения, основанные на Spring.

Объекты Groovy в Spring

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

В качестве примера представьте, что у вас есть интерфейс, определяющий формирование документа PDF из объектов типа Invoice (листинг 1).

Листинг 1. Интерфейс PdfGenerator
public interface PdfGenerator {
    byte[] pdfFor(Invoice invoice);
}

Интерфейс PdfGenerator выступает в роли контракта для реализующего его класса на Groovy. Реализация интерфейсов в Groovy аналогична Java, поэтому не представляет сложностей. В листинге 2 показан пример реализации этого интерфейса с использованием библиотеки iText (см. Ресурсы) для генерации PDF. Метод возвращает массив байт, представляющий собой содержимое в формате PDF.

Листинг 2. GroovyPdfGenerator
class GroovyPdfGenerator implements PdfGenerator {

    String companyName

    public byte[] pdfFor(Invoice invoice) {
        Document document = new Document(PageSize.LETTER)
        ByteArrayOutputStream output = new ByteArrayOutputStream()
        PdfWriter.getInstance(document, output)
        document.open()
        Font headerFont = new Font(family: Font.HELVETICA, size: 24.0, style: Font.ITALIC)
        document.add(new Paragraph("$companyName", headerFont))
        document.add(new Paragraph("Invoice $invoice.orderNumber"))
        document.add(new Paragraph("Total amount: \$ ${invoice.total}"))
        document.close()
        output.toByteArray()
    }
}

Итак, класс GroovyPdfGenerator готов к использованию. Он содержит строковое свойство companyName, использующееся в сгенерированном счете в формате PDF наряду с номером заказа и итоговой суммой. Теперь все готово к тому, чтобы интегрировать класс GroovyPdfGenerator в приложение на основе Spring. В то время как классы, написанные на Java, обязательно должны компилироваться в файлы .class, в случае работы с Groovy возможны следующие варианты:

  • скомпилировать Groovy-класс в файл .class аналогично Java;
  • оставить класс или скрипт Groovy в файле с расширением .groovy;
  • поместить скрипт на Groovy непосредственно внутрь конфигурационного класса Spring.

Существуют несколько вариантов определения и конфигурирования объектов Groovy в контексте Spring, которые зависят от того, какой из вариантов, перечисленных выше, вы выберете. Далее мы рассмотрим каждую из этих возможностей.

Конфигурирование объектов Groovy

Как правило, объекты Spring, написанные на Java, конфигурируются либо в XML, либо (начиная со Spring 2.5, см. Ресурсы) при помощи аннотаций, которые позволяют существенно сократить объем конфигурационного кода. Набор доступных способов конфигурирования объектов Groovy зависит от того, используете вы скомпилированные классы Groovy или классы, определенные в файлах с расширением .groovy. Главный момент заключается в том, что, написав нужные классы на Groovy, вы можете либо скомпилировать их аналогично тому, как вы поступаете в Java, либо оставить их в виде классов или скриптов в файлах .groovy, возложив на Spring обязанность скомпилировать их в момент создания контекста приложения.

Если вы решили создавать объекты в виде файлов .groovy, то вам не нужно компилировать их самостоятельно. Spring будет считывать исходный код скриптов на этапе выполнения приложения, компилировать его и помещать в контекст приложения. Такой подход обеспечивает большую гибкость, чем при обычной компиляции, поскольку файлы .groovy необязательно должны включаться внутрь архива WAR или JAR. Вместо этого они могут располагаться в файловой системе или быть доступны по URL.

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

Конфигурирования компилируемых классов Groovy

Конфигурирование скомпилированного класса Groovy, представленного в виде файла .class, ничем не отличается от конфигурирования объекта Java Bean. Если вы заранее скомпилировали класс GroovyPdfGenerator при помощи компилятора groovyc, то его объект можно описывать в XML-файле Spring обычным образом (пример приведен в листинге 3).

Листинг 3. Конфигурирование объекта скомпилированного класса GroovyPdfGenerator в XML
<bean id="pdfGenerator" class="groovierspring.GroovyPdfGenerator">
    <property name="companyName" value="Groovy Bookstore"/>
</bean>

Конфигурация в листинге 3 представляет собой классический пример описания объекта в Spring. При этом тот факт, что данный класс был реализован на Groovy, не имеет никакого значения. Любой компонент приложения, ссылающийся на объект pdfGenerator, может свободно его использовать, не зная и не заботясь о деталях его реализации, в том числе языке. Свойства этого объекта также можно описывать традиционным образом при помощи элемента <property> (в Spring 2.0 появилось пространство имен p, позволяющее описывать свойства более лаконичным образом, но мы будем использовать теги <property>, поскольку, на мой взгляд, они более удобочитаемы. Впрочем, это дело вкуса).

Если вы работаете со Spring версии 2.5 или старше, то для конфигурирования объекта GroovyPdfGenerator можно использовать аннотации. В этом случае вместо XML-описания объекта в контексте приложения достаточно добавить аннотацию @Component к объявлению класса (листинг 4).

Листинг 4. Пример использования аннотации @Component при определении объекта класса GroovyPdfGenerator
@Component("pdfGenerator")
class GroovyPdfGenerator implements PdfGenerator {
    ...
}

Пример включения режима конфигурирования при помощи аннотаций, а также сканирования компонентов, определенных в XML-контексте приложения Spring, показан в листинге 5.

Листинг 5. Пример конфигурирования при помощи аннотаций и включение режима сканирования компонентов
<context:annotation-config/>
<context:component-scan base-package="groovierspring"/>

Вне зависимости от того, конфигурируете вы объект Groovy в XML или при помощи аннотаций, помните, что сам процесс в точности соответствует конфигурированию объектов, написанных на Java.

Конфигурирование объектов, представленных в виде скриптов Groovy

Конфигурирование объектов Groovy, описанных в файлах .groovy, несильно отличается от конфигурирования объектов скомпилированных классов. Тем не менее, механизм работы с такими объектами представляет значительно больший интерес. Механизм преобразования скриптов Groovy в объекты включает в себя чтение кода скрипта, его компилирование, а также помещение объекта в контекст приложения Spring. В качестве примера определим объект, типом которого будет являться GroovyScriptFactory, указав при этом путь к скрипту Groovy (листинг 6).

Листинг 6. Определение объекта типа GroovyScriptFactory
<bean id="pdfGenerator"
      class="org.springframework.scripting.groovy.GroovyScriptFactory">
    <constructor-arg value="classpath:groovierspring/GroovyPdfGenerator.groovy"/>
    <property name="companyName" value="Groovier Bookstore"/>
</bean>

В этом примере классом объекта pdfGenerator является GroovyScriptFactory. При помощи элемента <constructor-arg> задается местоположение конфигурируемого скрипта на Groovy. Обратите внимание, что данный элемент указывает именно на скрипт, а не на скомпилированный класс. Значения свойств объектов, определенных в скриптах, задаются точно так же, как и значения обычных объектов в Spring. Пример приведен в листинге 6, в котором значение свойства companyName задается ожидаемым образом, т. е. при помощи элемента <property>.

В скрипте GroovyPdfGenerator.groovy должен содержаться как минимум один класс, реализующий интерфейс PdfGenerator. Как правило, стоит следовать стандартной практике программирования на Java и объявлять каждый класс Groovy в собственном файле. Однако в некоторых случаях может иметь смысл предоставить самому скрипту определять тип создаваемых объектов. Например, можно определить две различные реализации интерфейса в скрипте GroovyPdfGenerator.groovy, причем выбор одной из них можно возложить непосредственно на сам скрипт. Пример такого подхода приведен в листинге 7, в котором выбор реализации делается на основе системного свойства.

Листинг 7. Пример определения нескольких классов в одном скрипте Groovy
class SimpleGroovyPdfGenerator implements PdfGenerator {
    ...
}

class ComplexGroovyPdfGenerator implements PdfGenerator {
    ...
}

def type = System.properties['generatorType']
if (type == 'simple')
    return new SimpleGroovyPdfGenerator()
}
else {
    return new ComplexGroovyPdfGenerator()
}

Как видно из этого примера, скрипт может выбирать реализацию интерфейса на основе системного свойства. Если значением системного свойства generatorType является simple, то скрипт создает и возвращает экземпляр типа SimpleGroovyPdfGenerator. В противном случае создается объект типа ComplexGroovyPdfGenerator. Оба класса реализуют интерфейс PdfGenerator, поэтому использующие их компоненты приложения Spring могут не заботиться о том, с какой именно реализацией они работают.

Обратите внимание, что значения свойств объекта, возвращенного скриптом, задаются так же, как и в листинге 6, в частности, если типом объекта будет ComplexGroovyPdfGenerator, то по-прежнему будет установлено свойство companyName. В случаях, когда не требуется дополнительной гибкости при манипулировании различными реализациями, можно определять по одному классу в каждом скрипте Groovy (листинг 8). При этом Spring самостоятельно найдет класс и создаст его экземпляр.

Листинг 8. Типичный пример реализации скриптового класса Groovy
class GroovyPdfGenerator implements PdfGenerator {
    ...
}

Возможно, вам покажется удивительным, что классом объекта в листинге 6 является GroovyScriptFactory. Это объясняется тем, что Spring создает объекты, определенные в скриптах, при помощи класса, реализующего интерфейс ScriptFactory (в данном случае, GroovyScriptFactory), а также объекта-постпроцессора ScriptFactoryPostProcessor, который занимается тем, что заменяет объект фабрики на экземпляры, созданные этой фабрики, на этапе выполнения. Конфигурирование постпроцессора показано в листинге 9.

Листинг 9. Определение объекта типа ScriptFactoryPostProcessor
<bean class="org.springframework.scripting.support.ScriptFactoryPostProcessor"/>

При загрузке контекста приложения Spring сначала создает объекты фабричных классов (в частности, объекты типа GroovyScriptFactory), а затем передает управление постпроцессору ScriptFactoryPostProcessor, который меняет все экземпляры фабрик на созданные ими скриптовые объекты. Например, в соответствии с конфигурацией, приведенной в листингах 6 и 9, типом объекта pdfGenerator будет groovierspring.GroovyPdfGenerator. Если вы переведете вывод журнальных сообщений Spirng на уровень отладки, то увидите, что при создании контекста Spring сначала создает экземпляр фабрики с именем scriptFactory.pdfGenerator, а уже затем ScriptFactoryPostProcessor использует эту фабрику для создания объекта pdfGenerator.

Теперь, когда вы познакомились с низкоуровневыми подробностями, связанными с конфигурированием скриптовых объектов Groovy с использованием GroovyScriptFactory и ScriptFactoryPostProcessor, можно рассмотреть значительно более простой способ достичь такого же результата. Специально для создания объектов, определенных в скриптах, Spring предоставляет XML-схему lang. Пример ее использования для описания объекта pdfGenerator приведен в листинге 10.

Листинг 10. Определение скриптового объекта при помощи элемента <lang:groovy>
<lang:groovy id="pdfGenerator"
             script-source="classpath:groovierspring/GroovyPdfGenerator.groovy">
    <lang:property name="companyName" value="Really Groovy Bookstore"/>
</lang:groovy>

Показанное выше описание объекта pdfGenerator позволяет достичь того же результата, что и более сложный вариант, приведенный в листингах 6 и 9, при этом являясь значительно более кратким и понятным. В элементе <lang:groovy> необходим атрибут script-source, в котором указывается местоположение скрипта Groovy. Кроме того, можно использовать теги <lang:property> для задания свойств скриптовых объектов. В целом определение объектов Groovy при помощи <lang:groovy> является предпочтительным, поскольку значительно упрощает понимание конфигурации приложений на основе Spring.

Конфигурирование вложенных скриптов Groovy

Для полноты описания необходимо отметить еще один способ использования объектов Groovy – путем помещения скриптов непосредственно внутрь описания объектов в контексте приложения. Пример такого способа определения объекта pdfGenerator приведен в листинге 11.

Листинг 11. Вложенное определение скриптового объекта
<lang:groovy id="pdfGenerator">
    <lang:inline-script>
        <![CDATA[
        class GroovyPdfGenerator implements PdfGenerator {
            ...
        }
        ]]>
    </lang:inline-script>
    <lang:property name="companyName" value="Icky Groovy Bookstore"/>
</lang:groovy>

В этом примере объект pdfGenerator определяется при помощи элементов <lang:groovy> и <lang:inline-script>, причем последний содержит скрипт, описывающий класс объекта. Как и ранее, значения свойств устанавливаются при помощи <lang:property>. Как нетрудно догадаться, я бы не рекомендовал использовать этот способ определения скриптовых объектов внутри конфигурационных XML-файлов (как и вообще помещать программный код внутрь XML).

Конфигурирование объектов при помощи Bean Builder в Grails

Инфраструктура Grails для создания Web-приложений внутри себя использует Spring. В ее состав входит компонент под названием Bean Builder, который позволяет описывать объекты Spring программным образом на языке Groovy (см. Ресурсы). Программный подход является потенциально более гибким, чем использование конфигурации в XML, поскольку он может включать в себя определенную логику определения объектов. Bean Builder позволяет описывать объекты Groovy, относящиеся как к скомпилированным, так и скриптовым классам. Пример описания объекта pdfGenerator компилируемого класса Groovy приведен в листинге 12.

Листинг 12. Определение объекта компилируемого класса Groovy при помощи Bean Builder
def builder = new grails.spring.BeanBuilder()
builder.beans {
    pdfGenerator(GroovyPdfGenerator) {
        companyName = 'Compiled BeanBuilder Bookstore'
    }
}
def appContext = builder.createApplicationContext()
def generator = context.pdfGenerator

В листинге 12 сначала создается экземпляр BeanBuilder, а затем вызывается его метод для создания объекта нужного типа. Каждый подобный вызов в совокупности с необязательным параметром-замыканием определяет объект и устанавливает значения его свойств. Например, pdfGenerator(GroovyPdfGenerator) определяет объект с именем pdfGenerator типа GroovyPdfGenerator, а в коде замыкания задается значение свойства companyName. Разумеется, можно определить несколько объектов внутри одного замыкания beans.

Bean Builder также позволяет создавать скриптовые Groovy-объекты, а не только экземпляры скомпилированных классов. Однако, Bean Builder не предоставляет функциональности, аналогичной <lang:groovy>, поэтому придется использовать фабрику GroovyScriptFactory в сочетании с объектом-постпроцессором ScriptFactoryPostProcessor. Пример такого варианта использования Bean Builder приведен в листинге 13.

Листинг 13. Определение скриптового объекта при помощи Bean Builder
def builder = new grails.spring.BeanBuilder()
builder.beans {
    pdfGenerator(GroovyScriptFactory,
                'classpath:groovierspring/GroovyPdfGenerator.groovy') {
        companyName = 'Scripted BeanBuilder Bookstore'
    }
    scriptFactoryPostProcessor(ScriptFactoryPostProcessor)
}
def appContext = builder.createApplicationContext()
def generator = context.pdfGenerator

Логически код в листинге 13 эквивалентен конфигурации, показанной в листингах 6 и 9. Единственной разницей является то, что в листинге 13 объекты описываются при помощи кода на Groovy. При этом типом объекта pdfGenerator является GroovyScriptFactory. Второй параметр задает местоположение скрипта, а значение свойства companyName, как и ранее, устанавливается внутри замыкания. Кроме того, в листинге используется объект с именем scriptFactoryPostProcessor типа ScriptFactoryPostProcessor, который меняет экземпляры фабрики на созданные ею скриптовые объекты нужных типов.

Какой вариант конфигурирования является наилучшим?

Итак, вы познакомились с несколькими способами конфигурирования объектов Groovy, относящихся как к компилируемым, так и скриптовым классам. Если вы используете Groovy в качестве замены Java, то конфигурирование объектов Groovy для вас ничем не будет отличаться от конфигурирования объектов Java. Для этой цели можно использовать как XML, так и аннотации.

Скриптовые объекты Groovy могут конфигурироваться несколькими способами, однако предпочтительным вариантом является использование <lang:groovy>, поскольку это делает описание более простым и понятным по сравнению с GroovyScriptFactory и ScriptFactoryPostProcessor или применением <lang:inline-script>.

Вы также увидели в деле компонент Bean Builder, входящий в состав Grails. Он представляет собой принципиально другой подход к созданию контекста Spring, чем тот, что используется в большинстве приложений. Его стоит использовать, если вы хотите описывать все ваши объекты на Groovy, а также иметь возможность программировать логику процесса конструирования объектов. При этом необходимо помнить, что работа с Bean Builder вынуждает вас использовать классы GroovyScriptFactory и ScriptFactoryPostProcessor при создании объектов.

Использование объектов Groovy

Конфигурирование объектов вкупе с набором различных вариантов для его осуществления – это самый сложный аспект интеграции Groovy и Spring (хотя, как вы могли убедиться, на самом деле он не очень труден). Само использование объектов Groovy в приложениях Spring не представляет особых трудностей. Более того, поддержка динамических языков в Spring делает процесс использования объектов фактически прозрачным для остального приложения, для которого не важны детали реализации. Таким образом, код приложения можно писать обычным образом, используя по мере необходимости все возможности Spring, в частности внедрение зависимостей, AOP и интеграцию со сторонними библиотеками.

В листинге 14 показан простой скрипт на Groovy, в котором из файла XML загружается контекст приложения Spring, затем создается объект генератора PDF, далее использующийся для генерации счета в формате PDF.

Листинг 14. Пример использования объектов Groovy в скрипте
def context = new ClassPathXmlApplicationContext("applicationContext.xml")
def generator = context.getBean("pdfGenerator")

Invoice invoice = new Invoice(orderNumber: "12345", orderDate: new Date())
invoice.lineItems = [
    new LineItem(quantity: 1, description: 'Groovy in Action (ebook)', price: 22.00),
    new LineItem(quantity: 1, description: 'Programming Erlang', price: 45.00),
    new LineItem(quantity: 2, description: 'iText in Action (ebook)', price: 22.00)
]

byte[] invoicePdf = generator.pdfFor(invoice)

FileOutputStream file = new FileOutputStream("Invoice-${invoice.orderNumber}.pdf")
file.withStream {
    file.write(invoicePdf)
}
println "Generated invoice $invoice.orderNumber"

Большая часть кода в листинге 14 относится к загрузке контекста Spring (ApplicationContext), а также созданию счета и записи его в файл. При этом использование объекта pdfGenerator для генерации счета занимает всего одну строчку кода. В типичном приложении Spring контекст загружается один раз при старте системы, после чего все компоненты могут использовать связи, установленные Spring. В Web-приложениях Spring можно настроить объект-слушатель контекста сервлета, чтобы контекст Spring был проинициализирован при старте приложения. Например, сервис генерации счетов в формате PDF мог бы выглядеть, как показано в листинге 15.

Листинг 15. Класс сервиса, использующего генератор документов PDF
@Service
public class InvoicePdfServiceImpl implements InvoicePdfService {

    @Autowired
    private PdfGenerator pdfGenerator;

    public byte[] generatePdf(Long invoiceId) {
        Invoice invoice = getInvoiceSomehow(invoiceId);
        return pdfGenerator.pdfFor(invoice);
    }

    // Остальная часть реализации...

}

Класс InvoicePdfServiceImpl в листинге 15, использующий экземпляр PdfGenerator, реализован на Java, хотя его легко можно было бы написать на Groovy. Класс GroovyPdfGenerator можно вызывать в любых компилируемых или скриптовых объектах, и InvoicePdfServiceImpl не исключение. Другими словами, использование Groovy (как и любого другого динамического языка) является совершенно прозрачным для других компонентов приложения. Это серьезное преимущество, поскольку оно позволяет ослабить зависимость между компонентами, существенно облегчить тестирование, а также выбирать язык программирование, который наилучшим образом подходит к решению конкретной задачи.

Заключение к первой части

Прочитав эту статью, вы узнали о различных способах конфигурирования объектов, написанных на Groovy, и их использования в приложениях на основе Spring. Groovy-классы можно компилировать аналогично классам в Java. Кроме того, можно использовать скриптовые объекты, конфигурируя их способами, показанными выше. Выбор способа конфигурирования зависит от того, каким образом вы используете Groovy в вашем приложении. Наконец, компилируемые и скриптовые объекты Groovy можно использовать совместно. На самом деле, если очень захотеть, то можно одновременно использовать объекты классов, написанных на языках Java, Groovy, JRuby и BeanShell, в одном приложении, хотя я бы этого не рекомендовал. Как разработчик, вы должны взвешенно оценивать все плюсы и минусы использования разных языков в одной системе.

Привлекательность Groovy по сравнению с Java в основном обусловлена гибкостью языка, которая проявляется, даже если использовать только компилируемые классы. Groovy оказывается еще более интересным вариантом благодаря тому, что Spring позволяет использовать объекты, определенные в скриптах. При этом вы можете реализовывать дополнительную логику внутри скриптовых объектов, еще повышая гибкость системы. Например, как было показано выше, можно динамически определять тип создаваемого объекта, руководствуясь бизнес-логикой при старте приложения. Кроме того, можно повысить гибкость развертывания Web-приложения, помещая скриптовые объекты в файлы .groovy, находящиеся вне архива WAR (в CLASSPATH приложения либо в другом месте файловой системы).

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, Open source
ArticleID=421103
ArticleTitle=Groovy и Spring: Oсновы интеграции
publish-date=08142009