Каково использование spring.net?

DI Framework может быть полезен, если вы хотите изменить большие фрагменты приложения без необходимости переписывать конструкторы. Например, вы можете захотеть использовать сервис потоковой передачи комет, который вы будете предоставлять через интерфейс, а позже решить, что вы предпочтете использовать специальную систему обмена сообщениями, такую ​​как MQ или RendezVous. Затем вы напишете адаптер для Mq, который учитывает общий фасад, и просто измените конфигурацию spring, чтобы использовать реализацию Mq, а не Comet.

Но ради любви к пони , не используйте Spring.Net для создания привязок MVVM / MVP / MVC для каждого представления или вы попадете в мир боли.

DI - отличный инструмент при использовании с parcimony, пожалуйста, не заканчивайте с 243 файлами конфигурации Spring, для здравомыслия ваших разработчиков.

Я думаю, что если вы сделаете больше в коде, а не используете разметку для привязки и т. Д., И у вас есть BAL / DAL DI, это может помочь в этом, потому что он может ввести правильную ссылку на бизнес-компонент (как один пример). У DI есть много других практических преимуществ, но тогда вы должны делать больше в коде и меньше в разметке.

Использование контейнера IOC, такого как Spring.Net, выгодно, так как он позволит вам выполнять модульное тестирование частей вашего пользовательского интерфейса, заменяя имитированные или специальные тестовые реализации интерфейсы приложений. В конечном итоге это должно сделать ваше приложение более удобным в обслуживании для будущих разработчиков.

Лично я бы порекомендовал использовать либо Castle, либо Unity, так как я добился большого успеха с обоими и нашел их оба, хотя и отличные, отличные фреймворки IOC.

Помимо компонента IOC, они также предоставляют другие изящные инструменты (например, AOP в Castle, перехват интерфейса в Unity), которым вы, несомненно, найдете применение в будущем, а наличие инфраструктуры IOC с самого начала - это ВСЕГДА намного проще, чем пытаться модернизировать его.

Его невероятно легко установить и настроить, хотя лично я не большой поклонник XML-конфигурации, поскольку некоторые из этих конфигурационных файлов могут превратиться в настоящий кошмар. Многие люди скажут вам, что это стоит делать только в том случае, если вы собираетесь менять местами компоненты, но почему бы просто не сделать это в любом случае В СЛУЧАЕ, если вы решите, что вам нужно сделать это позже. лучше иметь и не использовать, чем не иметь и нуждаться в нем. Если вы беспокоитесь о производительности, я видел во многих сообщениях в блогах в Интернете, что люди сравнивают различные структуры МОК по их скорости, и если вы не создаете роботов для хирургии мозга или платформу противоракетной обороны США, это не будет проблемой .

>> "Выгодно ли нам использовать Spring.Net?"

Я думаю, что дух вашего вопроса больше направлен на то, чтобы задать вопрос о преимуществах использования IoC/DI фреймворка по сравнению с ручным управлением зависимостями по мере необходимости. Мой ответ будет больше сосредоточен на том, почему и почему нет IoC/DI, а не на том, какой конкретно фреймворк использовать.

Как отметил Мартин Фаулер на недавней конференции, DI позволяет отделить конфигурацию от использования. Для меня размышления об DI в свете конфигурации и использования как отдельных проблем - отличный способ начать задавать правильные вопросы. Есть ли необходимость в том, чтобы ваше приложение имело несколько конфигураций для зависимостей? Нужна ли вашему приложению возможность изменять поведение с помощью конфигурации? Имейте в виду, это означает, что зависимости разрешаются во время выполнения и обычно требуют XML-файл конфигурации, что очень удобно, поскольку изменения могут быть внесены без необходимости перекомпиляции сборки. Лично я не являюсь поклонником конфигурации зависимостей на основе XML, поскольку в итоге они воспринимаются как "волшебные строки". Существует опасность появления ошибок во время выполнения, если вы неправильно напишете имя класса и т.д. Но если вам нужна возможность конфигурирования "на лету", это, вероятно, лучшее решение на сегодняшний день.

С другой стороны, существуют DI-фреймворки, такие как Ninject и StructureMap, которые позволяют свободно определять зависимости в коде. Вы теряете возможность изменять определения "на лету", но получаете дополнительное преимущество в виде валидации во время компиляции, что мне больше нравится. Если все, что вам нужно от DI-фреймворка, - это разрешение зависимостей, то вы можете исключить из уравнения фреймворки на основе XML.

С точки зрения Silverlight, DI можно использовать различными способами. Наиболее очевидным является определение отношений представлений к моделям представлений. Однако, углубляясь, вы можете определить валидацию, зависимости контекста RIA и т.д. Наличие всех зависимостей, определенных в классе конфигурации, избавляет код от необходимости знать, как получить/создать экземпляры, и вместо этого сосредоточиться на использовании. Не забывайте, что контейнер может управлять временем жизни каждого экземпляра объекта на основе вашей конфигурации. Так что если вам нужно разделить экземпляр типа (например, Singleton, ManagedThread и т.д.), это поддерживается объявлением области времени жизни каждого типа, зарегистрированного в контейнере.

Я только что понял, что в этот момент я разглагольствую, и прошу прощения. Надеюсь, это поможет!