Замок Виндзор есть ли минусы?

Question

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

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

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

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

Answer 1

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

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

• Нет, это не так. В большинстве случаев при регистрации компонента используется небольшое отражение. Он также может использовать отражение при создании типа прокси, когда вы впервые запрашиваете компонент из контейнера.

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

• http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html
• http://www.codinginstinct.com/2008/04/ioc-benchmark-revisited-ninject.html
• http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html

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

Answer 7

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

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

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

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