Аннотации имеют свое использование, но они не одна серебряная пуля для уничтожения конфигурации XML. Я рекомендую смешать два!
, Например, при использовании Spring, это совершенно интуитивно для использования XML для части внедрения зависимости приложения. Это получает зависимости кода далеко от кода, который будет использовать его, в отличие от этого, с помощью своего рода аннотации в коде, для которого нужны зависимости, делает код, знающий об этой автоматической конфигурации.
Однако вместо того, чтобы использовать XML для транзакционного управления, отмечая метод как транзакционный с аннотацией имеет смысл, так как это - информация, которую программист, вероятно, хотел бы знать. Но что интерфейс будет введенным, поскольку SubtypeY вместо SubtypeX не должен быть включен в класс, потому что, если теперь Вы хотите ввести SubtypeX, необходимо изменить код, тогда как у Вас был интерфейсный контракт прежде так или иначе, таким образом, с XML, необходимо будет просто изменить отображения XML, и это является довольно быстрым и безболезненным, чтобы сделать так.
я не использовал аннотации JPA, таким образом, я не знаю, насколько хороший они, но я утверждал бы, что отъезд отображения бобов к базе данных в XML также хорош, поскольку объект не должен заботиться, куда его информация прибыла из, это должно просто заботиться о том, что это может сделать с его информацией. Но если Вам нравится JPA (у меня нет опыта с ним), любой ценой, пойдите для него.
В целом: Если аннотация обеспечивает функциональность и действует как комментарий в и себя и не привязывает код к некоторому определенному процессу для функционирования обычно без этой аннотации, то пойдите для аннотаций. Например, транзакционный метод, отмеченный как являющийся транзакционным, не уничтожает свою операционную логику и служит хорошим комментарием уровня кода также. Иначе эта информация, вероятно, лучше всего выражается как XML, потому что, хотя это будет в конечном счете влиять, как код работает, он не изменит основную функциональность кода и следовательно не принадлежит исходных файлов.
Я мог бы быть неправым, но я думал, что Аннотации (как в @Tag и C# Java [Атрибут]) были опцией времени компиляции, и XML был опцией во время выполнения. Это мне говорит, что не эквивалентный и имеет различные за и против.
Это - классическая 'Конфигурация по сравнению с Конвенцией' вопрос. Персональный вкус диктует ответ в большинстве случаев. Однако лично я предпочитаю Конфигурацию (т.е. базирующийся XML) по Конвенции. IMO IDE достаточно достаточно устойчив для преодоления некоторых людей ада XML часто, связывают w/создание и поддержка XML базирующийся подход. В конце я нахожу, что преимущества Конфигурации (такие как создание утилит, чтобы создать, поддержать и развернуть файл конфигурации XML) перевешивают Конвенцию в конечном счете.
Я также думаю, что соединение является лучшей вещью, но это также зависит от типа параметров конфигурации. Я работаю над проектом Шва, который также использует Spring, и я обычно развертываю его на другой разработке и тестовых серверах. Таким образом, я разделил:
основное отличие - то, что Вы не должны перекомпилировать код для всех изменяющихся определенных для сервера конфигураций, просто отредактировать XML-файл. Существует также преимущество, что некоторые изменения конфигурации могут быть сделаны членами команды, которые не понимают весь включенный код.
Это зависит от того, что все Вы хотите настроить, потому что существуют некоторые опции, которые не могут быть настроены с аннотациями. Если мы видим его со стороны аннотаций:
Вам решать, что более важно...
В целом я рекомендовал бы выбрать один путь и использовать все это по некоторой закрытой части продукта...
(за некоторыми исключениями: например, если Вы выбираете основанные на XML конфигурации, нормально использовать @Autowire аннотацию. Это смешивается, но этот помогает и удобочитаемости и пригодности для обслуживания)
Я всегда думаю об аннотациях как некоторый индикатор , что класс способен к, или , как он взаимодействует с другими.
конфигурация XML Spring, с другой стороны, мне просто, что, конфигурация
, Например, информация о IP и порте прокси, определенно входит в XML-файл, это - конфигурация во время выполнения.
Используя @Autowire
, @Element
для указания на платформу, что сделать с классом, хорошее использование аннотаций.
Помещение URL в @Webservice
аннотация является плохим стилем.
, Но это - просто мое мнение. Путь между взаимодействием и конфигурацией не всегда свободен.
Я использую обоих. Главным образом XML, но когда у меня есть набор бобов, которые наследовались общему классу и имеют общую собственность, я использую аннотации для тех в суперклассе, таким образом, я не должен устанавливать те же свойства для каждого боба. Поскольку я - немного любитель командовать, я использую @Resource (имя = "referredBean") вместо того, чтобы просто автосоединить материал проводом (и сохраняю меня большая проблема, если мне когда-нибудь нужен другой боб того же класса как исходный referredBean).
Я использовал Пружину в течение нескольких лет теперь и суммы XML, который требовался, определенно становился утомительным. Между новыми XML-схемами и поддержка аннотации в Spring 2.5 я обычно делаю эти вещи:
Используя "сканирование компонента" для автозагрузки классов, которые используют @Repository, @Service или @Component. Я обычно даю каждому бобу имя и затем соединяю их проводом вместе использующий @Resource. Я нахожу, что эта инфраструктура не изменяется очень часто, таким образом, аннотации имеют смысл.
Используя "aop" пространство имен для всего AOP. Это действительно работает отлично. Я все еще использую его для транзакций также, потому что помещение @Transactional повсеместно, своего рода перетаскивают. Можно создать названный pointcuts для методов на любом сервисе или репозитории и очень быстро применить совет.
я использую LocalContainerEntityManagerFactoryBean наряду с HibernateJpaVendorAdapter для конфигурирования, в спящем режиме. Это позволяет, в спящем режиме, легко автообнаруживают @Entity классы на пути к классу. Затем я создаю именованный боб SessionFactory с помощью "боба фабрики" и "метода фабрики", относящегося к LCEMFB.
Важная часть в использовании подхода только для аннотации - то, что понятие "бобового имени" более или менее уходит (становится незначительным).
"бобовые имена" в Spring формируют дополнительный уровень из абстракции по классам с реализацией. С бобами XML определены и сосланы относительно их бобового имени. С аннотациями на них ссылается их класс/интерфейс. (Хотя бобовое имя существует, Вы не должны знать это)
, я сильно полагаю, что избавление от лишних абстракций упрощает системы и улучшает производительность. Для большой проекты я думаю, что усиления путем избавления от XML могут быть существенными.
Здесь есть более широкая проблема, проблема внешнего или встроенного мета- данные. Если ваша объектная модель будет сохраняться только одним способом, то встроенные метаданные (т. Е. Аннотации) будут более компактными и читаемыми.
Если, однако, ваша объектная модель была повторно использована в разных приложениях таким образом, что каждый приложение хотело сохранить модель по-разному, тогда внешнее использование метаданных (т.е. XML-дескрипторов) становится более подходящим.
Ни один из них не лучше, поэтому оба поддерживаются, хотя аннотации более модны. В результате в новых фреймворках типа «волосы в огне», таких как JPA, им уделяется больше внимания. Более зрелые API, такие как собственный Hibernate, предлагают и то, и другое, потому что
Я думаю, что прозрачность - это большая победа для подхода, основанного на XML. Я считаю, что XML на самом деле не так уж плох, учитывая различные инструменты для навигации по XML-документам (например, окно Visual Studio + ReSharper's File Structure).
Вы, конечно, можете использовать смешанный подход, но это кажется мне опасным хотя бы потому, что потенциально Новым разработчикам в проекте было бы сложно понять, где сконфигурированы или сопоставлены различные объекты
Я не знаю; в конце концов, XML Hell мне не кажется таким уж плохим.
В рамках контейнера DI я считаю, что DI на основе аннотаций злоупотребляет использованием аннотаций Java. Сказав это, я не рекомендую широко использовать его в вашем проекте. Если вашему проекту действительно нужна мощь контейнера DI, я бы рекомендовал использовать Spring IoC с опцией конфигурации на основе Xml.
Если это просто ради модульного тестирования, разработчики должны применять шаблон Dependency Inject в своем коде и пользоваться преимуществами имитирующих инструментов, таких как EasyMock или JMock, для обхода зависимостей.
Вам следует избегать использования контейнера DI в неправильном контексте.