различия между контейнерами МОК
Я не использую VB.NET (я раньше использовал простой VB), но...
действительно ли ведущая точка обязательна? Если так, тогда я не вижу проблемы. В JavaScript результат использования with состоит в том, что свойство объекта смотрит все равно как простая переменная, и , что очень опасно, поскольку Вы не видите, получаете ли Вы доступ к свойству, или переменная, и таким образом, with является чем-то для предотвращения.
Не только его использование, легче на глазах, но и для повторного доступа к свойствам объекта, это, вероятно, будет быстрее, поскольку объект выбирается через цепочку метода только однажды, и не однажды для каждого свойства.
я действительно соглашаюсь с другими ответами, что необходимо избежать вложенного использования with по той же причине как, почему избежать with в целом в JavaScript: потому что Вы больше не видите то, что возражает, что Ваше свойство принадлежит.
4 ответа
Вот полезное сообщение в блоге , в котором сравниваются функции различных фреймворков IOC, доступных в .Net, я не знаю, есть ли в MVC что-то такое, что отдает предпочтение одному контейнеру над другим хотя.
Макс
Одна вещь, которая различается между различными контейнерами IoC, - это режимы жизненного цикла или создания экземпляров, которые поддерживаются из коробки (когда создавать новый экземпляр компонента):
- StructureMap
- временный (называемый по запросу), одноэлементный, локальный поток, по HttpContext, по HttpSession, гибридный
- Ninject
- временный, одноэлементный, на поток, на HttpRequest
- Castle Windsor
- singleton, transient, per-thread, pooled, per-HttpRequest (дополнительно доступно через средства)
- autofac
- временный (заводской), одноэлементный, на каждый запрос HttpRequest
- Unity
- временный, одноэлементный, на поток
Я лично остановился на Autofac. Одна вещь, которая кажется действительно приятной, - это детерминированное распределение ресурсов.
Это, а также интеграция с ASP.Net, когда я ее проверял. Я должен когда-нибудь взглянуть на другие фреймворки, но у меня с ними не было проблем. Сообщения об ошибках, которые он выдает, когда есть неразрешимый компонент, действительно хороши.
Лучше всего попробовать проекты с каждым из них. Я стал настоящим фанатом делать конфигурации в коде (насколько это возможно) и использовать конфигурации XML в качестве резервных. Так что составьте свой собственный список приоритетов и попробуйте их.
Лично - здесь ООП перестает быть правильным решением, потому что оно не так хорошо обрабатывает IoC. Возможно, лучше будет найти собственное решение. Лично я использую F # - пока я могу контролировать оба конца.
Новый Rx может помочь в некоторых из этих проблем, но все же он просто заимствует бандаж из функционального программирования.
Я думаю, мы застряли с Однако какое-то время объекты в качестве базовой модели для некоторых вещей - к счастью, в веб-сервисах объекты работали настолько плохо, что стандарты уже отошли от них в сторону функциональных интерфейсов, таких как SOAP.