Конфігурація Xml проти конфігурації на основі анотацій [закрито]

У кількох великих проектах, над якими я працював останнім часом, здається, що все більш важливим стає вибір того чи іншого (XML або Анотація). У міру зростання проектів послідовність дуже важлива для ремонту.

Мої запитання: які переваги конфігурації на основі XML перед конфігурацією на основі анотацій та які переваги конфігурації на основі анотацій перед конфігурацією на основі XML?

Анотації використовують їх, але вони не є однією срібною кулею для вбивства конфігурації XML. Я рекомендую змішати два!

Наприклад, якщо ви використовуєте Spring, використовувати XML для частини ін'єкції залежності вашої програми цілком інтуїтивно. Це позбавляє залежності коду від коду, який буде ним користуватися, навпаки, використання якоїсь анотації в коді, яка потребує залежності, робить код відомим про цю автоматичну конфігурацію.

Однак, замість використання XML для управління транзакціями, маркування методу як транзакційного з анотацією має ідеальний сенс, оскільки це інформація, яку, мабуть, хотів би знати програміст. Але що інтерфейс буде вводитись як SubtypeY замість SubtypeX, не слід включати до класу, тому що, якщо тепер ви хочете вставити SubtypeX, ви повинні змінити свій код, тоді як раніше у вас був контракт на інтерфейс, так що з XML вам просто потрібно буде змінити відображення XML, і це зробити досить швидко і безболісно.

Я не використовував анотації JPA, тому не знаю, наскільки вони хороші, але я б стверджував, що залишати відображення бобів у базі даних у XML також добре, оскільки об’єкт не повинен перейматися, звідки надходить його інформація. , вона повинна просто дбати про те, що вона може зробити зі своєю інформацією. Але якщо вам подобається JPA (я не маю жодного досвіду з цим), будь-ласка, займіться цим.

Загалом: Якщо анотація забезпечує функціональність і виступає як коментар сама по собі, і не прив'язує код до певного конкретного процесу, щоб нормально функціонувати без цієї анотації, тоді перейдіть до анотацій. Наприклад, транзакційний метод, позначений як транзакційний, не вбиває його логіки роботи, а також слугує хорошим коментарем на рівні коду. В іншому випадку ця інформація, ймовірно, найкраще виражається як XML, оскільки, хоча вона з часом вплине на функціонування коду, вона не змінить основної функціональності коду, а значить, не належить до вихідних файлів.

Тут є більш широке питання, яке стосується зовнішніх та вбудованих метаданих. Якщо ваша об'єктна модель зберігатиметься лише одним способом, то вкладені метадані (тобто анотації) є більш компактними та читабельними.

Якщо, однак, вашу об'єктну модель повторно використали в різних додатках таким чином, щоб кожна програма хотіла зберігати модель по-різному, то екстерналізація метаданих (тобто дескрипторів XML) стає більш доцільною.

Жоден з них не є кращим, і тому обидва підтримуються, хоча примітки є більш модними. Як результат, нові рамки для вогню, такі як JPA, як правило, приділяють їм більше уваги. Більш зрілі API, такі як рідний сплячий, пропонують і те, і інше, оскільки відомо, що жодного з них недостатньо.

Я завжди думаю про примітки як про якийсь показник того, на що здатний клас чи як він взаємодіє з іншими.

З іншого боку, весна конфігурація XML для мене - це лише те, що конфігурація

Наприклад, інформація про ip та порт проксі, безумовно, йде у XML-файл, це конфігурація часу виконання.

Використання @Autowire, @Elementщоб вказати рамки , що робити з класом добре використання анотацій.

Внесення URL-адреси в @Webserviceпримітку - це поганий стиль.

Але це лише моя думка. Межа взаємодії та конфігурації не завжди чітка.

Я використовую Spring вже кілька років, і потрібна кількість XML напевно набридає. Між новими схемами XML та підтримкою анотацій навесні 2.5 я зазвичай виконую такі дії:

1. Використання "сканування компонентів" для автоматичного завантаження класів, які використовують @Repository, @Service або @Component. Зазвичай я даю ім’я кожному бобу, а потім з'єдную їх разом, використовуючи @Resource. Я вважаю, що ця сантехніка змінюється не дуже часто, тому анотації мають сенс.

2. Використання простору імен "aop" для всіх AOP. Це справді чудово працює. Я все ще використовую його для транзакцій, тому що розміщення @Transactional у всьому місці - це певний затяг. Ви можете створити іменовані точкові розрізи для методів на будь-якій службі чи сховищі та дуже швидко застосувати поради.

3. Я використовую LocalContainerEntityManagerFactoryBean разом із HibernateJpaVendorAdapter для налаштування Hibernate. Це дозволяє Hibernate легко автоматично розкривати класи @Entity на classpath. Потім я створюю іменований боб SessionFactory, використовуючи "фабрику-фасуль" і "заводський метод" з посиланням на LCEMFB.

Важливою частиною використання підходу, що стосується лише анотації, є те, що поняття "ім'я квасолі" більш-менш відходить (стає незначним).

"Імена квасолі" навесні утворюють додатковий рівень абстрагування над навчальними класами. З XML боби визначаються та посилаються відносно їх назви квасолі. З анотаціями на них посилається їх клас / інтерфейс. (Хоча назва квасолі існує, вам її не потрібно знати)

Я твердо вірю, що позбавлення від зайвих абстракцій спрощує системи та підвищує продуктивність. Для великих проектів я думаю, що виграш від позбавлення від XML може бути значним.

Я думаю, що завдяки підходу, заснованому на XML, видимість - це велика перемога. Я вважаю, що XML насправді не такий вже й поганий, враховуючи різні інструменти для навігації по XML-документах (тобто вікно структури файлів Visual Studio + ReSharper).

Ви, звичайно, можете скористатися змішаним підходом, але це здається мені небезпечним хоча б тому, що, можливо, новим розробникам у проекті буде важко розібратися, де налаштовані чи відображені різні об’єкти.

Не знаю; врешті-решт, XML Hell не здається мені таким поганим.

Це залежить від того, що все ви хочете налаштувати, оскільки є деякі параметри, які неможливо налаштувати за допомогою анотацій. Якщо ми бачимо це з боку анотацій:

• плюс: анотації менш балакучі
• мінус: анотації менш помітні

Це саме від вас, що важливіше ...

Загалом, я б рекомендував вибрати один із способів і використовувати його на якійсь закритій частині продукту ...

(за деякими винятками: наприклад, якщо ви вибираєте конфігурації на основі XML, нормально використовувати анотацію @Autowire. Це змішування, але це допомагає як читати, так і ремонтувати)

Є й інші аспекти для порівняння, такі як рефакторинг та інші зміни коду. при використанні XML потрібно робити серйозні зусилля, щоб зробити рефакторинг, оскільки вам потрібно подбати про весь вміст XML. Але це легко при використанні Анотацій.

Мій кращий спосіб - це конфігурація на основі Java без (або мінімальних) анотацій. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Я можу помилятися, але я вважав, що Анотації (як у @Tag та атрибуті C # на Java) є варіантом часу компіляції, а XML - варіантом виконання. Це, як мені кажуть, не рівнозначні і мають різні плюси і мінуси.

Я також вважаю, що суміш - це найкраща річ, але це також залежить від типу параметрів конфігурації. Я працюю над проектом Seam, який також використовує Spring, і я зазвичай розгортаю його на різних розробниках і тестових серверах. Тому я розділив:

• Конфігурація сервера (як абсолютні шляхи до ресурсів на сервері): Весняний XML-файл
• Впорскування квасолі як членів інших бобів (або повторне використання визначеного значення Spring XML у багатьох квасолях): Анотації

Ключова відмінність полягає в тому, що вам не доведеться перекомпілювати код для всіх змінних конфігурацій, характерних для сервера, просто відредагуйте файл xml. Також є перевага в тому, що деякі зміни конфігурації можуть бути здійснені членами команди, які не розуміють весь код, що стосується.

В області контейнера DI я вважаю, що DI на основі анотацій зловживає використанням анотації Java. Сказавши це, я не рекомендую широко використовувати його у своєму проекті. Якщо ваш проект дійсно потребує потужності контейнера DI, я рекомендую використовувати Spring IoC з опцією конфігурації на основі Xml.

Якщо це просто заради Unit-test, розробники повинні застосовувати шаблон кодування залежностей у своєму кодуванні та користуватися перевагами з глузливих інструментів, таких як EasyMock або JMock, щоб обійти залежності.

Вам слід намагатися уникати використання контейнера DI у його неправильному контексті.

Інформація про конфігурацію, яка завжди буде пов'язана з певним компонентом Java (класом, методом або полем), є хорошим кандидатом, який повинен бути представлений анотаціями. Анотації особливо добре спрацьовують у цьому випадку, коли конфігурація є основною для призначення коду. Через обмеження в анотаціях також найкраще, коли кожен компонент може мати лише одну конфігурацію. Якщо вам потрібно мати справу з декількома конфігураціями, особливо тими, які залежать від будь-якого поза класом Java, що містить примітки, анотації можуть створити більше проблем, ніж вони вирішують. Нарешті, анотації неможливо змінити без перекомпіляції вихідного коду Java, тому все, що потрібно перенастроювати під час виконання, не може використовувати анотації.

Перейдіть за наступними посиланнями. Вони також можуть бути корисними.

1. Анотації проти XML, переваги та недоліки
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Це класичне питання "Конфігурація проти Конвенції". Особистий смак диктує відповідь у більшості випадків. Однак особисто я віддаю перевагу конфігурації (тобто на основі XML) над конвенцією. IMO IDE є достатньо надійними, щоб подолати деякі пекло XML, які часто асоціюються з будівництвом та підтримкою підходу, заснованого на XML. Зрештою, я знаходжу переваги конфігурації (такі як побудова утиліт для побудови, підтримки та розгортання файлу конфігурації XML) в довгостроковій перспективі переважує Конвенцію.

Я використовую і те, і інше. Переважно XML, але коли у мене є купа квасолі, яка успадковується із загального класу та має загальні властивості, я використовую примітки для них у надкласі, тому мені не потрібно встановлювати однакові властивості для кожного квасолі. Оскільки я трохи контрольний фрік, я використовую @Resource (name = "referenceBean") замість того, щоб просто провести автоматичне з'єднання (і заощаджую собі багато клопотів, якщо мені коли-небудь потрібна інша квасоля того ж класу, що і оригінальна referenceBean) .

З мого досвіду є деякі плюси і мінуси конфігурації приміток:

• Що стосується конфігурації JPA, оскільки вона робиться один раз і зазвичай не змінюється досить часто, я вважаю за краще дотримуватися конфігурації анотацій. Може виникнути занепокоєння щодо можливості побачити більшу картину конфігурації - в цьому випадку я використовую діаграми MSQLWorkbench.
• Конфігурація Xml дуже хороша для отримання більш широкої картини програми, але, можливо, громіздко знайти деякі помилки до часу виконання. У цьому випадку анотація Spring @Configuration є кращим вибором, оскільки вона дозволяє вам бачити більшу картину, а також дозволяє перевірити конфігурацію під час компіляції.
• Що стосується конфігурації Spring, то я вважаю за краще поєднувати обидва підходи: використовувати анотацію @Configuration з інтерфейсами служб та запитів та конфігурацію xml для елементів конфігурації даних та джерела, таких як контекст: компонент-сканування base-package = "..."
• Але конфігурація XML біт анотацій Java, якщо мова йде про конфігурацію потоку (Spring Web Flow або Lexaden Web Flow), оскільки вкрай важливо бачити більшу картину всього бізнес-процесу. І звучить громіздко, якщо це реалізується з підходом до анотацій.

Я вважаю за краще поєднувати обидва підходи - java анотації та необхідний мінімум xml, що мінімізує конфігурацію.

Для Spring Framework мені подобається можливість використовувати анотацію @Component і встановити параметр "сканування компонентів", щоб Spring міг знайти мої Java-боби, щоб мені не довелося визначати всі мої квасолі в XML, ні в JavaConfig. Наприклад, для бездомних яєвих бобів без громадянства, які просто потрібно підключити до інших класів (за допомогою інтерфейсу в ідеалі), такий підхід працює дуже добре. Взагалі, для весняних бобів я здебільшого віддалився від Spring XML DSL для визначення бобів, і тепер надаю перевагу використанню JavaConfig та Spring Annotations, тому що ви отримуєте деякий час перевірки конфігурації та деяку підтримку рефакторингу, яку ви не використовуєте. не можна отримати конфігурацію Spring XML. Я змішую ці два в певних рідкісних випадках, коли я виявив, що JavaConfig / Анотації не можуть робити те, що доступно за допомогою конфігурації XML.

Для Hibernate ORM (ще не використовував JPA) я все ще віддаю перевагу файлам відображення XML, оскільки анотації в класах доменних моделей певною мірою порушують чисту архітектуру, що є багатошаровим архітектурним стилем, який я прийняв за останні кілька років. Порушення виникає через те, що він вимагає, щоб базовий шар залежав від речей, пов'язаних зі стійкістю, таких як бібліотеки Hibernate або JPA, і це робить POJOs доменної моделі трохи меншою наполегливістю. Насправді основний шар взагалі не повинен залежати від будь-якої іншої інфраструктури.

Однак якщо «Чиста архітектура» не є вашою «чашкою чаю», то я можу побачити, що є певні переваги (наприклад, зручність та ремонтопридатність) використання анотацій зі сплячки / JPA в класах доменних моделей над окремими файлами відображення XML.