У замка Виндзор есть минусы?
Я изучал проект «Замок» и, в частности, Виндзор. Я был так впечатлен тем, что возможно с этой технологией, и преимущества наличия такой слабосвязанной системы определенно очевидны. Единственное, в чем я не уверен, - есть ли у этого метода какие-либо недостатки, особенно в asp.net? например хиты производительности и т. д.
Я пытаюсь показать преимущества этого подхода моим коллегам-разработчикам, и меня ждут следующие отклики:
Это использует отражение, и каждый раз, когда объект вызывается из контейнера, отражение должно использоваться, поэтому производительность будет ужасной. (Это так? Используется ли отражение при каждом вызове?)
Если я полагаюсь на интерфейсы; как мне работать с объектами, у которых есть дополнительные методы и свойства, прикрепленные к классу? (по наследству)
Ответы 7
Одна проблема с Castle Windsor, с которой я столкнулся, заключается в том, что он не может работать в Medium Trust (без перекомпиляции, которую я не смог сделать). Поэтому мне нужно было переключиться с Windsor на Unity.
Согласно производительности DI / IoC - я считаю, что падение производительности невелико, особенно если иметь в виду его мощность.
Кстати: если вы начинаете с DI / IoC, вам следует прочитать эта статья MSDN.
О компиляции Windsor для работы на Medium Trust, возможно, это поможет: vhendriks.wordpress.com/2007/11/21/monorail-on-shared-hostin g
Значительные затраты на запуск, почти не снижается производительность во время работы (конечно, без отражения для вызовов - все компилируется во время инстанцирования). Виндзор немного тяжелый, но при правильном управлении сроком службы не должно вызывать никаких проблем.
Более важным недостатком является то, что проблемы интеграции не обнаруживаются во время сборки, а некоторые даже при запуске. Без тщательного отслеживания версий всех модулей и постоянного тестирования всей системы легко попасть в беду. Здесь помогает отражение, поэтому Windsor лучше в этом аспекте, чем многие другие фреймворки DI.
По поводу производительности смотрите эти статьи:
- 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.
интересное чтение в качестве сравнения фреймворков IOC (что здорово), но последний график по первой ссылке показывает, что падение производительности при использовании IOC по сравнению с "новым" значительно
Определенно, он должен быть медленнее, чем простой оператор new. Я согласен с тем, что операции, критичные к скорости, должны выполняться без DI / IoC. Но в большинстве случаев это хорошо для получаемых способностей.
Кроме того, подумайте об абсолютном времени создания нового экземпляра. Даже если с DI / IoC требуется в 10 раз больше времени, я думаю, что это не узкое место приложения (если вы не создаете миллионы экземпляров), и снижение производительности не является значительным (по сравнению с другими операциями).
увы, меня действительно беспокоит приложение, создающее миллионы экземпляров, поэтому я зациклен на цифрах - думаю, я попробую Windsor в следующем проекте :)
Виндзор - хорошее место для начала. Теперь я использую Unity (лучше для использования с Enterprise Library и Medium trust)
Скорость контейнеров IoC не является проблемой для подавляющего большинства приложений. Характеристики каждого контейнера способ более важны для сравнения.
Я использовал контейнеры IoC (Spring.NET и StructureMap) в нескольких производственных приложениях при высокой нагрузке (не на Facebook / MySpace, но достаточно, чтобы вывести из строя несколько серверов).
По моему опыту, еще до того, как я начал использовать IoC, самой большой проблемой производительности была база данных и взаимодействие с базой данных - оптимизация запросов, индексов, использование кэширования 2-го уровня и т. д.
Если у вас есть база данных, связанная с вашим приложением, то любое поражение производительности, которое может вызвать Виндзор или любой другой контейнер, будет настолько бесконечно малым по сравнению с обходом DB туда и обратно.
Это похоже на людей, которые сравнивают снижение производительности оператора new () и Activator.CreateInstance () за 1–10 мс, когда один обход БД обычно на порядок дороже.
Я бы посоветовал вам не беспокоиться о мелочах и сосредоточиться на большом.
Кроме того, я хотел бы посоветовать вам взглянуть на StructureMap, так как я считаю, что он имеет гораздо больше функциональных возможностей, чем Windsor, и не имеет многих недостатков Windsor (то есть держится за ссылки и требует от вас их выпустить и т. д.) .
Хэмметт совершил Component Burden пару месяцев назад (mail-archive.com/[email protected]/…)
-1. получение ресурсов - это инициализация; как вы можете проверить время жизни ваших объектов, если нет метаданных о стиле жизни, которые распространяются через вызов разрешения? Или как насчет одноразовых объектов, которые зависят от того, что вы разрешаете; как бы вы выполнили их вручную? Это не недостаток. В MVC, например Часть выпуска связана либо с контроллером, либо с образом жизни по запросу, и Виндзор обрабатывает это за вас!
Я использовал StructureMap и Windsor, а с Windsor мне пришлось гораздо больше возиться с жизненными циклами и настраивать их. С StructureMap это просто работает. Он обрабатывает все те же сценарии, но более очевидным образом. Виндзор заставляет задуматься об этом больше, в чем нет необходимости в 99% случаев.
Чтобы ответить на ваши вопросы:
- That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)
- Нет. В большинстве случаев при регистрации компонента используется небольшое отражение. Он также может использовать отражение при генерации типа прокси, когда вы впервые запрашиваете компонент из контейнера.
- If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)
- Все дело в дизайне. Вы не хотите, чтобы каждый объект создавался контейнером. Вы используете его в первую очередь для служебных зависимостей. В этом случае вас не волнует, какой тип на самом деле скрывается за интерфейсом (в этом весь смысл, не так ли?).
Вы также можете иметь компоненты класса, но у них есть ограничения, и вы должны знать о них (например, вы не можете перехватывать вызовы невиртуальных методов). Я считаю Windsor наиболее зрелым и наиболее подходящим для моего стиля разработки.
Кроме этого, «Производительность», я не слышал о проекте, в котором пришлось бы отказаться от контейнера зависимостей из-за неприемлемой производительности. Windsor действительно умен и кэширует результаты длительных операций, так что вам не придется платить дважды. В Интернете можно найти диаграммы, сравнивающие скорость многих контейнеров IoC. В связи с этим следует отметить две вещи: все контейнеры действительно быстрые. Не думайте, что тот факт, что другие контейнеры быстрее на этих графиках, чем Виндзор, означает, что они лучше. Виндзор делает для вас много чего, чего не делают другие контейнеры.
Последующий вопрос здесь. stackoverflow.com/questions/2216684/…
Согласованы по производительности, так как это может быть действительно низко висящий фрукт, если вы просто найдете более быстрый контейнер. Взгляните на этот пост в блоге для более подробной информации - после прочтения я переключился на Funq и увидел приличный выигрыш: palmmedia.de/blog/2011/8/30/…
Единственное исключение, когда производительность контейнера IoC неприемлема, по моему опыту, - это попытка интегрировать / обернуть контейнер IoC как IServiceProvider для использования в ComponentModel - когда-то распространенным примером этого было создание собственного размещенного конструктора winforms (обычно для создать своего рода нестандартный дизайнер, например рабочий процесс / блок-схему и т. д.)
Из-за особенностей поведения ряда компонентов winforms, особенно во время разработки, стоимость разрешения компонента физически заставит мышь "заикаться" при перетаскивании, потому что фреймворк может выполнять до 30 000 вызовов разрешения службы в секунду - это больше. размышления о плохой практике кодирования в самих компонентах, хотя я думаю, или, по крайней мере, из-за предположений, сделанных о том, что реализация поставщиков услуг будет быстрой / простой.
На практике я никогда не обнаруживал, что время разрешения компонентов является проблемой даже в сильно загруженных коммерческих приложениях.
- That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)
Насколько известно, все хорошие контейнеры (включая Castle Windsor) действительно используют отражение для создания новых экземпляров. Однако это улучшение производительности. Это для сравнения с Activator.CreateInstance, который работает намного медленнее. Некоторые другие контейнеры довольно быстрые и могут составить конкуренцию новому оператору. См. Сравнительный тест здесь. Castle Windsor не из самых высокопроизводительных, но скорость не особо важна. Когда дело доходит до использования IoC в приложении. 90% ваших классов должны быть установлены как синглтоны, а это означает, что они будут работать только при запуске вашего приложения.
- If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)
Попробуйте эти руководства по руководство и это. Это откроет ответ на ваш вопрос. Если вы хотите избежать проблем с дизайном и простое в обслуживании программное обеспечение, я настоятельно рекомендую использовать ТВЕРДЫЕ практики.