У замка Виндзор есть какие-то недостатки?

Я изучал проект Замка и, в частности, Виндзор. Я был настолько впечатлен тем, что возможно с этой технологией, и преимущества наличия такой слабосвязанной системы определенно очевидны. Единственное, что я не уверен в том, что если использование этого метода имеет какие-то недостатки, особенно в asp.net? например, хиты производительности и т.д.

Я стараюсь, чтобы преимущества этого подхода были видны моим коллегам-разработчикам здесь, и меня поражают следующими возвращениями:

  • Это использование отражения, и каждый раз, когда объект вызывается из контейнера, должно использоваться отражение, поэтому производительность будет ужасной. (В этом случае? Использует ли он отражение при каждом вызове?)

  • Если я полагаюсь на интерфейсы; как я могу обращаться с объектами, которые имеют дополнительные методы и свойства, которые были привязаны к классу? (через наследование)

ОТВЕТЫ

Ответ 1

Чтобы ответить на ваши вопросы:

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

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

Кроме того, Performance, я не слышал о проекте, который должен был отказаться от контейнера зависимостей из-за неприемлемой производительности. Виндзор действительно сообразителен, и он кэширует результаты длительных операций, так что вам не придется платить цену дважды. Вы можете найти диаграммы в Интернете, сравнивая скорость многих контейнеров IoC. Следует отметить две вещи: все контейнеры очень быстрые. Не думайте, что тот факт, что другие контейнеры быстрее на этих графиках, чем Виндзор, означает, что они лучше. Виндзор делает много вещей для вас, что другие контейнеры не делают.

Ответ 2

Я использовал контейнеры IoC (Spring.NET и StructureMap) в нескольких производственных приложениях с высокой нагрузкой (а не на Facebook/MySpace, но достаточно, чтобы подчеркнуть несколько серверов).

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

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

Это похоже на людей, которые сравнивают хит производительности нового оператора() по сравнению с Activator.CreateInstance() в 1-10 мс, когда однократное перемещение DB обычно на порядок дороже.

Я бы посоветовал вам не беспокоиться о мелочах и сосредоточиться на большом материале.

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

Ответ 3

Одна проблема с Castle Windsor, с которой я столкнулся, заключается в том, что она не может работать в Medium Trust (без перекомпиляции, которую я не смог сделать). Поэтому мне нужно было перейти от Виндзора к Единству.

В соответствии с производительностью DI/IoC - я считаю, что удар производительности невелик, особенно если вы помните о мощности, которую он имеет.

BTW: Если вы начинаете с DI/IoC, вы должны прочитать эту статью MSDN.

Ответ 4

Значительные затраты на запуск, почти не влияющие на производительность во время работы (без отражения для звонков, конечно, все, скомпилированное во время создания экземпляра). Windsor немного тяжелее, но при правильном управлении временем не должно возникать никаких проблем.

Более важным недостатком является то, что проблемы интеграции не возникают во время сборки, а некоторые даже не запускаются. Без тщательного отслеживания версий всех модулей и непрерывного тестирования всей системы легко попасть в неприятности. Отражение помогает здесь, поэтому Windsor лучше в этом аспекте, чем многие другие рамки DI.

Ответ 5

Единственное исключение, когда производительность контейнера IoC неприемлемо в моем опыте, заключается в попытке интегрировать/обернуть контейнер IoC в качестве IServiceProvider для использования в ComponentModel - некогда общий пример этого заключался в создании собственного размещенного конструктора winforms (обычно для создания своего рода пользовательского конструктора, то есть рабочего процесса/блок-схемы и т.д.)

В связи с тем, как ведет себя несколько компонентов winforms, особенно во время разработки, стоимость решения компонента физически заставляет мыши "заикаться" при перетаскивании, потому что фреймворк может сделать более 30 000 вызовов разрешения на обслуживание вторым - это скорее отражается на плохой практике кодирования в самих компонентах, хотя я думаю, или, по крайней мере, из-за предположений о том, что реализация поставщиков услуг выполняется быстро/просто.

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

Ответ 6

Что касается производительности, см. следующие статьи:

Но помните, что некоторые из этих контейнеров имеют более новые (и, вероятно, более быстрые) версии - особенно Unity.

Ответ 7

  • Это использование отражения и каждый раз, когда объект вызывается из контейнера, должно использоваться отражение, поэтому производительность будет ужасно. (В этом случае? Использует ли он отражение при каждом вызове?)

Насколько известно всем хорошим контейнерам (включенным здесь замок Виндзор), используйте рефлексию для создания новых экземпляров. Однако это повышает производительность. Это нужно сравнить с Activator.CreateInstance, который намного медленнее. Некоторые другие контейнеры довольно быстрые и могут конкурировать с новым оператором. См. Таблицу сравнения здесь. Замок Виндзор не от высоких исполнителей, но скорость не очень важна. Когда дело доходит до использования IoC в приложении. 90% ваших классов должны быть установлены как однотонные, и это означает, что вы работаете только при запуске своего приложения.

  1. Если я полагаюсь на интерфейсы; как я могу обращаться с объектами, которые имеют дополнительные методы и свойства, которые были привязаны к классу? (через наследование)

Попробуйте этот учебник и этот учебник. Он покажет ответ на ваш вопрос. Если вы хотите избежать проблем с дизайном и простым в обслуживании программном обеспечении, я настоятельно рекомендую перейти на SOLID practice