Как вы справляетесь с дополнительной сложностью, добавленной весенними бобами?

Question

Я пишу программное обеспечение уже много лет и всегда старался создать выразительный, четко читаемый, поддерживаемый, надежный код. Недавно я присоединился к команде, разрабатывающей веб-приложения с использованием Spring-управляемых объектов. Но мне очень неудобно с этой технологией. Для меня это похоже на то, что все принципы инкапсуляции и скрытия информации, достижения десятилетий разработки программного обеспечения были просто оставлены. Я ясно вижу плюсы использования контейнера Inversion of Control, для перемещения системных зависимостей из кода программы в файлы конфигурации. Но теперь я вижу, что Spring используется так, как я чувствую, просто добавляет ненужную сложность, не принося никакой пользы.

Использование Spring для создания бэкэнсов, поддерживающих webapp, объекты уже не четко организованы в модулях и не имеют минимальной видимости. Вместо этого теперь существует одно глобальное пространство имен компонентов. Из-за этого объекты, как правило, получают ужасные имена, такие как «pendingOrderCustomerName», и, чтобы усугубить ситуацию, такие имена даже не четко идентифицируют четко определенный объект, потому что определения bean могут исходить из различных источников определения, собранных из явно определенных местоположений: Вместо того, чтобы просто определять класс в пакете, Spring beans собираются из xml-файлов, со свободными возможностями переопределения и слабо определенными отношениями.

Например, когда у меня есть тип «Учетная запись» в простой Java, в пакете «my.webstore», я обычно знаю о свойствах, отношениях и способностях этого типа в одном месте, «my/webstore/Account.java ". Экземпляры «Учетной записи» существуют как ссылки на объекты, работающие с учетными записями, состояние любого экземпляра точно определяется классом. С весенними бобами все усложняется: экземпляр «Учетная запись» теперь существует под глобальным именем в области управления, управляемой контейнером, с состоянием, собираемым из xml-файлов, найденным вдоль пути поиска файла на основе шаблонов именования ...

Прошли те дни, когда, чтобы понять, что делает объект и как он себя ведет, вам просто нужно было прочитать его источник программы. Сегодня вам нужен источник java объекта (который может быть достаточно сложным для понимания), плюс вы должны найти любые файлы конфигурации, которые могут изменить этот объект, что непросто, потому что вам нужно выяснить все способы, из которых могут возникнуть конфигурации и вы должны выяснить, в каком порядке они переопределяют друг друга

Может быть, это просто дело вкуса, но мне тоже интересно, почему люди предпочитают многословный, неуклюжий синтаксис XML, как:

<bean id="p1" class="Point" scope="prototype"> 
    <property name="x"> 
     <value>20</value> 
    </property> 
    <property name="y"> 
     <value>80</value> 
    </property> 
    </bean> 

над это:

p1 = new Point(20,80); 

T его пример может показаться преувеличенным, но я говорю вам, что я видел хуже!

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

Answer 1

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

Проблема заключается в том, что люди знают, как использовать Spring, но не почему. Особенно, когда не использовать его. Весенние бобы полезны, когда у вас есть несколько реализаций. Именно там заливается зависимость. В вашем примере я, конечно, надеюсь, что Point не имеет каких-либо других реализаций, и, таким образом, Spring снова используется неправильно.

Для меня Guice motivation мотивировал меня, чтобы понять больше об инъекции зависимостей, он одинаково хорошо относится к весне.

Сказали, что вы можете проверить Spring's annotations, чтобы узнать, как ваша конфигурация и код могут храниться в одном месте.

Answer 2

Как вы видели, довольно легко злоупотреблять Spring, если вы не понимаете правильно принципы объектно-ориентированного дизайна. Контейнер Spring IoC (давайте забудем об остальном сейчас, так как есть огромный портфель библиотек под весенний зонтик) действительно сияет, когда вы используете его:

• определить компонентную модель (например, контроллеры, услуги, хранилища и их зависимости)
• централизовать поиск компонента зависимостей (например, заменить сервис локаторы, JNDI Lookups или другие стратегии извлечения компонентов без гражданства)
• компоненты украсить технические аспекты (например, управлением транзакциями, кэширование, контроль доступа и т.д.)

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

Наверняка вы ничего не выиграете (и фактически проиграете много), если вы начнете определять Account s и Point s как компоненты пружины. Они все равно должны быть созданы как объекты или объекты ценности. Они все равно должны быть частью надлежащего пакета, и должны применяться соответствующие модификаторы видимости. Они все равно должны быть созданы, управляться и управляться с помощью стратегий, которые вы использовали бы, если ваше приложение не использовало контейнер IoC.

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

Я также рекомендую вам изучить, как использовать объявления @Component и <context:component-scan>, чтобы уменьшить размер XML-данных.

Удачи.