Каковы Профессионалы/Недостатки Аннотаций (некомпилятор) по сравнению с xml файлами конфигурации
Предположение, что Вы знаете, что корневые элементы являются нулем, вот является псевдокодом для вывода к тексту:
function PrintLevel (int curr, int level)
//print the indents
for (i=1; i<=level; i++)
print a tab
print curr \n;
for each child in the table with a parent of curr
PrintLevel (child, level+1)
for each elementID where the parentid is zero
PrintLevel(elementID, 0)
2 ответа
Хорошее эмпирическое правило: все, что вы видите, что хотите изменить без полного повторного развертывания (например, настройка параметров производительности), действительно должно быть помещено во что-то «мягко настраиваемое», такое как файл XML. Все, что реально никогда не изменится - или только в той ситуации, когда вам все равно придется изменить код - может быть разумно помещено в аннотацию.
Игнорируйте любые идеи о различиях в производительности между аннотациями и XML - если только ваша конфигурация абсолютно огромная разница будет незначительной.
Сконцентрируйтесь на гибкости и удобочитаемости.
Если вы пишете API, одно предупреждение: аннотации могут просочиться в ваш общедоступный интерфейс, что может вызвать невероятное раздражение.
В настоящее время я работаю с API, где поставщик API добавил в свою реализацию аннотации Spring MBean , что внезапно означает, что у меня есть зависимость от библиотек Spring, несмотря на то, что мне может не понадобиться использовать Spring вообще: (
(Конечно, если бы ваш API был расширением самого Spring, это могло бы быть верным предположением.)