Ознакомился с документацией, все логично и понятно.
Теперь хотелось бы понаблюдать в деле.
Подскажите проекты с открытым исходным кодом, которые можно было бы скачать, изучить.
В которых применяется этот подход.
Желательно что бы метадата была в XML , а не в виде аннотаций.
Спасибо.
Здравствуйте, Аноним, Вы писали:
А>Ознакомился с документацией, все логично и понятно. А>Теперь хотелось бы понаблюдать в деле. А>Подскажите проекты с открытым исходным кодом, которые можно было бы скачать, изучить. А>В которых применяется этот подход. А>Желательно что бы метадата была в XML , а не в виде аннотаций.
Может слегка оффтоп, но все же: я имел опыт применения Spring.NET IoC в коммерческом проекте.
Опыт показал, что xml-файлы с описанием контейнеров имеют ужасную сопровождаемость.
У нас там было примерно 100 килобайт спрингового xml-я и это было крайне безблагодатно.
Здравствуйте, Аноним, Вы писали:
А>Ознакомился с документацией, все логично и понятно. А>Теперь хотелось бы понаблюдать в деле. А>Подскажите проекты с открытым исходным кодом, которые можно было бы скачать, изучить. А>В которых применяется этот подход. А>Желательно что бы метадата была в XML , а не в виде аннотаций. А>Спасибо.
Тут трудно советовать не зная конкретной ситуации.
Я могу себя считать фанатом Spring фреймворка вообще и IoC в частности.
Но я к этому пришел из определенных требований в определенных проектах.
Нужно ли это все Вам — это еще неизвестно. А самое нехорошее обычно выходит когда пытаются использовать в принципе неплохую вешь без особой надобности.
Поэтому я бы посоветовал сначала собрать список из нескольких пунктов на тему "мои проблемы, которые я надеюсь решить с помошью Spring IoC" и как минимум обдумать альтернативы для каждого пункта.
А по поводу XML и аннотаций я участвовал во многих спорах на эту тему и пришел к следующему выводу:
1. Если зависимость неизменна в принципе(например отображение сущности на таблицу), аннотация тут смотрится лучше
2. Если возможно измененик зависимости(например замена реального модуля заглушкой), XML более удобен
Плюс к этому второй пункт иногда является эдакой документацией(всегда актуальной!) на high-level архитектуру приложения. Что иногда очень помогает.
Но все это очень зависит от ситуации.
Здравствуйте, 0x7be, Вы писали:
0>Опыт показал, что xml-файлы с описанием контейнеров имеют ужасную сопровождаемость. 0>У нас там было примерно 100 килобайт спрингового xml-я и это было крайне безблагодатно.
Здравствуйте, robin_of_the_wood, Вы писали:
___>Тут трудно советовать не зная конкретной ситуации. ___>Я могу себя считать фанатом Spring фреймворка вообще и IoC в частности. ___>Но я к этому пришел из определенных требований в определенных проектах. ___>Нужно ли это все Вам — это еще неизвестно. А самое нехорошее обычно выходит когда пытаются использовать в принципе неплохую вешь без особой надобности. ___>Поэтому я бы посоветовал сначала собрать список из нескольких пунктов на тему "мои проблемы, которые я надеюсь решить с помошью Spring IoC" и как минимум обдумать альтернативы для каждого пункта.
___>А по поводу XML и аннотаций я участвовал во многих спорах на эту тему и пришел к следующему выводу: ___>1. Если зависимость неизменна в принципе(например отображение сущности на таблицу), аннотация тут смотрится лучше ___>2. Если возможно измененик зависимости(например замена реального модуля заглушкой), XML более удобен ___>Плюс к этому второй пункт иногда является эдакой документацией(всегда актуальной!) на high-level архитектуру приложения. Что иногда очень помогает. ___>Но все это очень зависит от ситуации.
Конкретная ситуация такая :
на работе с этой технологией не сталкивался, было немного свободного времени — решил ознакомится для саморазвития.
С Вами согласен по поводу поиска решения под конкретную проблему.Но в данном случае хотелось бы именно увидеть те проблемы которые IoC помогает решить в реальных проектах.
Сложилось мнение что более useful это связка аннотаций и xml, конечно в зависимости от ситуации.
