Какая польза от Spring.net?

Question

Мы разрабатываем приложение, используя Silverlight и WCF Services. Насколько выгодно использование Spring.Net для нас?

Answer 1

>> «Является ли использование Spring.Net выгодным для нас?»

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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