Ну по-перше, крім XML-конфігурації Spring допускає настройку за допомогою анотацій, що деякі вважають більш зручним підходом.
А взагалі, Spring - це більше ніж просто IoC контейнер, хоч той і є його ключовою частиною. Spring - великий фреймворк зі своєю сферою застосування. Свого часу на проект ми відмовилися від нього на користь google-guice, тому що потрібен був тільки IoC.
integral. Spring Roo - convention over configuration і ніякого XML
це все добре, але не відповідає на питання: навіщо мені потрібен Spring в моєму додатку?
А ніхто не гарантує, що він обов'язково потрібен вам у вашому додатку. Швидше за все, раз таке питання постало - то таки не потрібен
А що-у вас за додаток-то?
Мова не про конкретний додаток, а скоріше продовження дискусії по-поводу використань спрінга у всіх додатках поспіль
А ви можете навести приклад доречного використання спрінга в додатку?
Спрінг доречний в разі, якщо додаток розгортається на томкате, наприклад, і потрібно автоматичне керування транзакціями і т.п.
Хоча я б в такому випадку встромив в томкат openejb.
Мені здається, найбільш доречно використовувати його якщо є перспектива використання в додатку АОП, транзакцій на рівні об'єктів, якщо ймовірна зміна моделі доступу до даних. Для реалізації веб-інтерфейсу я його не використав ніколи, але чув про декілька важливих фічах, як то Spring Web MVC + Spring Web Flow, Spring security. Ну і інші цікаві технології типу JMX, JMI, RPC (RMI, SOAP)
Зрозуміло, можна вибрати будь-який стек технологій, це вже скоріше справа смаку і досвіду роботи з кожною з них. Головне, без фанатизму. У великому проекті з АОП ми використовували Spring, для чистого IoC-контейнера без надмірностей - не стали.
Spring зародився як альтернатива ЇЇ - мовляв, надто громіздко для більшості випадків. І не можуть зупинитися. Тепер це "наше все" і самі стають монстрами.
Навіщо потрібен спринг з його xml-конфігураційним файлом і невже заради IoC люди возяться з ним?
Якщо розглядати тільки IoC, то:
1. Без IoC програми відображаються убого через використання Фабрик і Одинаків, що робить додатки важко тестованим і дерев'яним.
2. Spring IoC - простий як пень, для його вивчення вистачить неповного дня (звичайно, для глибоких пізнань дня не вистачить, проте глибокі знання не повинні бути, щоб вміти користуватися DI).
3. Для IoC не обов'язково використовувати Spring: є той же Guice, можна і самому зварганити IoC Фабрику, хоча не впевнений, що це прокотить на великих додатках.
Dependency Inversion Principle, Low Coupling, High Cohesion, отже: легкість перевикористання компонент і розуміння коду.
До речі, ІМХО, дуже правильне питання. Сам я пручався Спрінг до останнього. Довелося використовувати, так як нічого кращого Spring Security не знайшов. Зараз використовую Spring Security і Spring JPA (+ JPA Generic Dao, + ZK).
* Нічого поганого про спринг сказати не можу, крім нажаль про 2-3 витрачених днями на написання xml конфігов. Плюс відчувається "тяжкість" спрінга на хостингу.
* Нічого хорошого про спринг поки теж сказати не можу. Таке враження, що все що робиться через спринг можна все робити якось простіше, через ті ж інструкції (нехай навіть і - через спринг на нижньому рівні, як працює в Grails).
ІМХО, для WEB розробки Spring - найкраще що є в Java.
Це продумане комплексне рішення. Єдиним мінусом якого є складна конфігурація. Але тут є ROO.
EE - для web розробки придатний погано. У JSF проблеми з SEO і юзабіліті. EJB не можна прив'язати до сесії користувача.
Показати всі посилання цього об'єкта:
Ви також можете додати свою фірму в каталог IT-фірм. і публікувати статті, новини, вакансії і іншу інформацію від імені фірми.
Generation time: 0.752