Мы используем МОК эффективно?

Ваши первые две проблемы не являются настоящими проблемами (почему так объясняет Финглас).

Я бы посчитал «Все зарегистрированные типы данных имеют конструктор по умолчанию» запахом кода (при условии, что класс загружает зависимости непосредственно из вашего контейнера IoC). Когда это происходит, это либо 1) точка входа приложения, где уместно получить объект из вашего контейнера Ioc (поскольку вам, вероятно, все равно нужно инициализировать этот контейнер Ioc), или 2) место, где вы могли бы использовать вместо этого фабрику.

Не рекомендуется использовать конструктор по умолчанию для заполнения зависимостей. Причина в том, что вы дублируете знания о том, как создать класс. В идеале каждый класс даже не должен знать, где находится ваш контейнер IoC - это задача точки входа вашего приложения.

Похоже, использование IoC в вашей компании в целом неплохое.

Все типы данных регистрируются в коде, а не в файле конфигурации.

Под типами данных, я полагаю, вы имеете в виду привязки. Например, IFoo должен быть связан с Foo . Если это так, ничего страшного. Фактически, это намного лучше в глазах многих людей (включая меня), чем указывать привязки через XML. Естественным преимуществом здесь является то, что проверки выполняются во время компиляции. Вы не будете программировать на XML , как говорится.

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

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

Эффективно ли моя компания использует IoC? Есть ли преимущество в создании новых объектов с помощью Windsor, чем в создании новых объектов с помощью нового ключевого слова?

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

Кроме того, инвертируя элемент управления, очень легко вносить изменения в модульные части приложения. Например, представьте, что вы хотите переключить модуль на лучшую версию.С контейнерами IOC вы просто изменяете одну или две строки привязок. Без IOC вам пришлось бы вручную пройти через приложение и убедиться, что оно правильно подключено внутри.

Это хороший вопрос, который относится к вашему последнему пункту о , почему вы должны использовать IOC вместо простых ручных методов.

Уверен, что другие опубликуют более подробные ответы, но вот что получилось у меня:

Все типы данных регистрируются в коде, а не в конфигурационном файле.

Существует тенденция в (по крайней мере в некоторых) IoC/Dependency Injection фреймворках регистрировать зависимости с помощью кода, а не XML Config. Основное преимущество заключается в том, что во время компиляции вы знаете, неправильно ли что-то подключено или нет. Например, если вы решите добавить/удалить аргумент конструктора, ваш код фактически не скомпилируется, если ваша конфигурация не синхронизирована (и это позволяет избежать проявления опечаток в виде случайных исключений нулевой ссылки во время выполнения).

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

Я не совсем понимаю, что вы имеете в виду под "одной реализацией интерфейса". Если вы имеете в виду, что интерфейсы сбрасываются на объекты, которые их реализуют, то это определенно не кошерно. Если нет, то есть преимущества в кодировании интерфейса, а не конкретной реализации. Главное из них - это возможность использовать объекты-макеты, поддерживающие интерфейс, в модульном тестировании. Программирование на основе интерфейса (в теории) заставляет вас делать ваш код более свободно связанным, что может помочь в тестировании. Это также открывает некоторые действительно классные варианты дизайна, как, например, вот этот Построение типового DAO с Hibernate и Spring AOP.

Все зарегистрированные типы данных имеют конструктор по умолчанию, поэтому Windsor не создает граф объектов для зарегистрированных типов.

Это также не обязательно плохо. Я думаю, что в целом эмпирическое правило гласит, что если зависимость имеет решающее значение для выполнения вашим классом своей функции, то следует использовать внедрение конструктора. Если нет (логирование, вероятно, самый часто используемый пример этого), то внедрение свойств является более подходящим вариантом. Хотя я не знаком с Castle Windsor, я знаю, что по крайней мере некоторые IoC-контейнеры Java не поддерживали инъекцию конструктора в ранних версиях (если кто-то, кто лучше знаком с Castle Windsor, может прокомментировать это, было бы здорово). Если Castle Windsor не имел этой возможности в ранних версиях, это также могло привести к конструкции, которую вы наблюдаете в своей системе.

Что касается использования IoC против вызова new везде, это также зависит от использования. В тех нескольких проектах, над которыми я работал, которые в значительной степени полагались на IoC (Spring в Java и Autofac в .NET), подключение всех зависимостей в одном месте позволило нам довольно быстро и безболезненно экспериментировать с иерархиями объектов и композицией.