Управление сложностью в приложении с зависимостями и большим количеством компонентов - PullRequest
Новая
       36

Управление сложностью в приложении с зависимостями и большим количеством компонентов

5 голосов
/ 12 июня 2009

Я работаю над приложением Spring, которое имеет большое количество bean-компонентов - из сотен - и оно становится довольно громоздким для использования и документирования.

Меня интересует любой ваш опыт работы с приложениями с поддержкой DI с большим количеством bean-компонентов, которые могут помочь в обслуживании, документировании и общем использовании.

Несмотря на то, что приложение основано на Spring с парой контекстных файлов, я открыт для прослушивания предложений относительно любого контейнера DI и в целом о DI.

Ответы [ 4 ]

6 голосов
/ 13 июня 2009

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

Пример: 


<beans>
  <!-- Scans service package looking for @Service annotated beans -->
  <context:component-scan base-package="my.root.package.service"/>

</beans>

Ваши классы обслуживания должны быть аннотированы для автоматического сканирования: 

<code>
package my.root.package.service;</p>

<p>@Service("fooService")
public class FooServiceImpl implements FooService{</p>

<p>}

Вы также можете использовать аннотацию @Autowired, чтобы сообщить Spring, как внедрить зависимости bean-компонента: 


package my.root.package.service;

@Service("barService")
public class BarServiceImpl implements BarService{
    //Foo service injected by Spring
    @Autowired
    private FooService fooService;

    //...
}
4 голосов
/ 12 июня 2009

Мне показалось полезным следующее:

  1. разделите ваши конфигурации Spring на несколько автономных конфигураций и используйте средство импорта Spring для импорта зависимостей конфигурации (см. здесь , раздел 3.2.2.1). Таким образом, у вас есть набор конфигураций, которые вы можете комбинировать или разбирать по мере необходимости, и все они являются независимыми (все зависимости будут явными и будут ссылаться)
  2. Используйте интегрированную среду разработки, поддерживающую Spring и позволяющую вам перемещаться по конфигурациям с помощью точечных нажатий на bean-компонентах (ссылки / имена, исходный код to-and-from). Intellij очень хорошо работает на этом (я думаю, версия 7 и выше). Я подозреваю, что Eclipse сделает что-то подобное.
  3. Пересмотреть что вы вводите где . Вы можете реорганизовать несколько инъекций bean-компонентов в один составной или «meta» bean-компонент или более крупный компонент. Или вы можете обнаружить, что компоненты, которые вы когда-то думали, что вам нужно внедрить, никогда не менялись или никогда не требовали такой инъекции (для тестирования, реализации в качестве стратегий и т. Д.)

Раньше я работал с огромной установкой Spring с сотнями (тысячами?) Бинов. Разделение конфигураций сделало жизнь намного более управляемой, а также упростила тестирование / создание автономных процессов и т. Д. Но я думаю, что интеграция с Intellij Spring, которая пришла с Intellij, имела самое большое значение. Использование среды разработки с поддержкой Spring значительно экономит время.

3 голосов
/ 14 июня 2009

Как говорит @Wilson Freitas, используйте автоматическую разводку. Я ежедневно работаю с системой, которая имеет несколько тысяч бинов с пружинным управлением, использующих в основном автоматическую разводку. Но я думаю, что понятие «сохранение общей картины» несколько неуместно. По мере роста системы вы не можете ожидать, что будете делать это так же, как в небольшой системе. Использование @Autowiring вынуждает вас использовать более строгую типизацию, чем пружины на основе xml, что снова означает, что вы можете использовать функции отслеживания зависимостей в вашей IDE для навигации по зависимостям.

Я действительно считаю неоптимальным думать, что вам нужно , чтобы понять слишком много "полной" картины, когда речь идет о конфигурации пружины. Вы должны сосредоточиться на своем коде и его зависимостях. Управляемость и ремонтопригодность достигаются путем правильной организации этого кода, правильного именования и управления связью; все вещи, которые применяются, даже если вы не используете пружину. Spring не должен сильно меняться, и с одобрением JSR-330 может даже показаться, что внедрение зависимостей будет ползти дальше «под капот» среды выполнения.

1 голос
/ 05 августа 2009

Наша стратегия:

  • соглашения об именах , например: fooService, fooDao, fooController;
  • установщики свойств в соответствии с этими соглашениями;
  • автопроводка по имени (autowire = "byName"); у нас было много проблем с автопроводкой по типу, особенно на уровне контроллера
...