Почему xml так заметно представлен в контейнерах IOC?

Question

Я пытаюсь попасть в контейнеры IOC и замечаю, что многие из них используют конфигурацию xml. Может ли кто-нибудь объяснить мне, почему многие новые технологии переходят на модели XML / config / программирования (WCF, WPF, Spring.NET, Unity, Windsor)? Кажется, что xml - плохой выбор для указания сложных настроек, и было бы лучше сделать это в коде, где все безопасно, и у нас есть intellisense. Я знаю, что некоторые могут посчитать это спорным, но мне действительно любопытно, почему эти, в остальном, очень крутые, передовые технологии полагаются на xml.

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

См. XML в контейнерах IoC: Ад или Царство для дальнейшего обсуждения.

Answer 5

В МОК и многих других "настраиваемых" технологиях.

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

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

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Answer 10

У вас может быть завершение кода для xml. Например, есть плагин eclipse для конфигурационных файлов Spring, который помимо прочего показывает javadoc свойства, заданного в качестве всплывающей подсказки, предлагает автозавершение для имен классов в вашем classpath, помечает любые ссылки на bean-компоненты, которые не могут быть разрешены внутри текущий файл и т. п.

Конфигурационные файлы на самом деле являются формой DSL - специально для настройки конфигурации приложения. Этот пошив позволяет легче выразить определенные вещи. Например, как бы вы обеспечили правильное завершение работы приложения (компонент должен быть выключен до его зависимостей) при инициализации компонентов в Java? Как бы вы сконфигурировали перехватчик на уровне вашего бизнес-сервиса?

Что касается того, почему они сделаны в XML, я предполагаю, что DSL был необходим, и XML имел преимущество существующего элементарного набора инструментов (редакторы, валидаторы, парсеры, ...).