Почему xml так заметно показан в контейнерах МОК?

Я переместил свою конфигурацию Unity в XML только по одной причине - я могу изменить конфигурацию без повторной компиляции моего кода. В некоторых случаях это очень полезно.

Это все равно что задаться вопросом, почему у молотка стальная головка, когда вы предпочитаете склеивать все вместе.

Сборка приложения во время выполнения из декларативных файлов конфигурации - это цель, сам DI - просто средство

Если вы можете кодировать конфигурацию, зачем вообще использовать IoC framework? Возьмите несколько более прочный дизайн и избавьтесь от лишней боли.

В общем, мне нравятся плавные интерфейсы для IoC, как предлагал mxmissile (я использую Unity).

Хотя это означает, что только разработчик может что-то изменить (как указал Мэтью Уайтед), как часто вы хотите, чтобы не-разработчик мог заменить один класс другим в вашем приложении? В таких случаях вы можете подготовить простой диалог конфигурации (поддерживаемый любым хранилищем данных, которое вы хотите) и получить результаты от этого управления для быстрой настройки. Это позволяет избежать проблем с хрупкостью и безопасностью. Потому что, если конечный пользователь испортит ваш файл конфигурации, вы, вероятно, будете обвинены в том, что приложение выйдет из строя.

Основной вариант использования, который у меня есть для изменения конфигураций, - это модульное тестирование.

Схема XML может быть проверена, что делает возможным "строго типизированный". Одна из основных причин его популярности в том, что его довольно легко понять, и существует так много фреймворков парсеров практически на любом языке программирования, который вы хотите. Ничто не мешает вам использовать плоский файл (например, фиксированной ширины или CSV), файлы INI, файлы JSON или даже пользовательские двоичные форматы, если хотите.

В IOC и многих других «настраиваемых» технологиях.

Дело в том, что XML стал стандартом для взаимодействия документов.

Таким образом, вместо того, чтобы каждый создавал свой собственный формат, все приняли «новый» формат.

Какое-то время это было хорошо, но со временем это стало раздражать, как вы указываете.

Что касается указания этого в коде, ну, дело в том, что иногда код приходится перекомпилировать, чтобы изменения вступили в силу в то время как XML является текстовым / простым, что позволяет изменять без перекомпиляции.

Появляются новые форматы, но ни один из них не оказал такого влияния, как XML.

Потому что это то, что делают все остальные в пространстве .net. Все началось с web.config, и люди начали его расширять. но я верю, что большинство этих технологий поддерживают как настройку с помощью XML, так и с помощью кода. Основное отличие будет заключаться в легкости, с которой не кодировщик, например системный администратор, ответственный за развертывание приложения, может изменить конфигурацию. Если это необходимо, то, на мой взгляд, XML все еще является жизнеспособным вариантом. Я действительно считаю, что мир .net начинает склоняться к соглашению по поводу конфигурации вместо того, чтобы помещать все в файлы конфигурации XML.

С тех пор в мире Java многое изменилось благодаря возможностям, предоставляемым использованием аннотаций, но вы должны прочитать Я не понимаю Spring Боба Ли, автора книги Google Guice .

РЕДАКТИРОВАТЬ: Как упоминалось в комментарии, несправедливо цитировать предыдущий пост без упоминания Я был слишком усерден в Spring ... . Теперь это исправлено. Спасибо, что напомнили мне об этом.

Контейнеры IoC следует рассматривать как механизмы рендеринга для непрограммного развертывания / настройки приложений, а не программные структуры для упрощения использования шаблона проектирования IoC.

Таким образом, XML используется в основном по двум причинам:

1. для явной визуализации семантики сконструированных приложений, а не вербализации процедур построения .
2. , чтобы код конфигурации был взаимозаменяемым между внешними разнородными приложениями, которые предоставляют дополнительные функции (такие как отображение конфигурации, проверка, преобразование и редактирование). То есть намерение состоит в том, чтобы открывать контейнеры посредством интеграции данных , а не интеграции API .

В Fluent API отсутствует проверка схемы модели данных, а также он очень негибкий для использования для предполагаемой интеграции данных,

You can have code completion for xml. For instance, there is an eclipse plugin for Spring configuration files that among other things shows the javadoc of the property being set as tooltip, offers auto-completion for the names of classes in your classpath, marks any bean references that could not be resolved within the current file etc. pp.

Configuration files are actually a form of DSL - tailored to express application configuration. This tailoring allows to express certain things more easily. For instance, how would you ensure proper application shutdown (a component must be shut down before its depedencies) when you initialize components in Java? How would you configure an interceptor around your business service layer?

As for why they are done in XML, I guess a DSL was required, and XML had the benefit of an existing rudimentary toolchain (editors, validators, parsers, ...).

Никто не упоминал, что XML может быть результатом преобразования XSLT, и что пользовательские DSL могут быть созданы таким образом поверх простой конфигурации IoC. Это очень мощный подход.