Я заметил, что другие ответы не касаются очень важной проблемы, которую конфигурация Fluent приносит вам реализацию DI. Это жесткие конкретные реализации для вашей базы кода, создающие, таким образом, тесно связанные зависимости ... что по иронии судьбы - это то, что IoC-контейнеры пытаются решить. Теперь вы обнаружите, что заражаете все свои приложения кодом регистрации компонента, что не очень хорошо звучит.
Почему это не звучит хорошо? Потому что, когда у вас есть распределенная система со многими приложениями, которые используют разные компоненты, у вас есть два варианта регистрации компонентов:
1. Добавьте код DI во все ваши приложения.
Как то так ...
var builder = new ContainerBuilder();
builder.RegisterType<ConsoleLogger>().As<ILogger>();
builder.RegisterType<EmailNotificationDispatcher>().As<INotificationDispatcher>();
builder.RegisterType<DefaultMessageHandler>().As<IMessageHandler>();
//many more...
и, конечно, ВСЕ приложения в системе будут нуждаться в подобной логике с различными компонентами.
Преимущества
Вы используете Fluent Configuration, потому что это довольно ... вот и все:)
Неудобство
- Эта легкая регистрация компонентов загрязняет все ваши приложения, включая БЕТОННЫЕ типы
- Вам нужно будет перекомпилировать свои приложения, если вам нужно поменять зависимость / компонент
- Если вам нужно перейти на другой инструмент контейнера IoC ... то же самое
2. Оберните ваш DI-код внутри компонента-оболочки, чтобы сделать ваши приложения независимыми от IoC-контейнера.
Как то так ...
public sealed class ComponentFactory
{
private static IContainer _container;
public static void Init()
{
var builder = new ContainerBuilder();
builder.RegisterType<ConsoleLogger>().As<ILogger>();
builder.RegisterType<EmailNotificationDispatcher>().As<INotificationDispatcher>();
builder.RegisterType<DefaultMessageHandler>().As<IMessageHandler>();
//many more...
_container = builder.Build();
}
public static T Resolve<T>()
{
return _container.Resolve<T>();
}
}
При таком подходе ваши приложения вообще не будут знать, какие конкретные классы они вообще используют.
Вам не нужно перекомпилировать и заново развертывать все приложения, если вам нужно поменять местами компоненты.
Более того, если вам нужно перейти на другой IoC-контейнер, изменения будут сделаны в одном месте - классе-оболочке.
Огромным недостатком этого подхода является то, что вам придется развертывать все компоненты в папке bin всех приложений, даже если есть компоненты (или двоичные сборки), в которых одно приложение может не понадобиться. Таким образом, ваши легкие приложения станут толстыми тяжелыми клиентами.
Конфигурация XML (или JSON)
При конфигурации xml ничего из вышеперечисленного не произойдет ...
- вы развертываете то, что нужно вашим приложениям ... для каждого приложения
- вы регистрируете компоненты, в которых нуждаются ваши приложения ... для отдельных приложений
- Ваши приложения легки и не имеют представления о конкретной реализации, которую они используют. Они становятся очень масштабируемыми
- есть больше, но, надеюсь, вы поняли идею
Сейчас я не сторонник XML-конфигурации, я ненавижу ее, я программист и предпочитаю свободный путь, а не XML (или JSON), но по моему опыту конфигурация XML / JSON оказывается более масштабируемой и поддерживаемой .
Теперь стреляй в меня !!!