Я использую Внедрение зависимости: какие типы я должен связать как одиночные элементы?

Существует много вопросов там о том, "плохи" ли одиночные элементы, и что шаблоны использовать вместо этого. Они обычно фокусируются на одноэлементном шаблоне разработки, который включает получение одноэлементного экземпляра от статического метода для класса. Это не один из тех вопросов.

С тех пор, как я действительно "обнаружил" внедрение зависимости несколько месяцев назад, я управлял его принятием в нашей команде, удаляя статические и шаблоны "одиночка" из нашего кода со временем, и с помощью основанной на конструкторе инжекции по мере возможности. Мы приняли конвенции так, чтобы мы не продолжали добавлять явную привязку к нашим модулям DI. Мы даже используем платформу DI для обеспечения экземпляров регистратора, так, чтобы мы могли автоматически сказать каждый регистратор, в каком классе это находится без дополнительного кода. Теперь, когда у меня есть единственное место, где я могу управлять, как различные типы связываются, действительно легко определить, каков жизненный цикл конкретной категории классов (служебные классы, репозитории, и т.д.) должен быть.

Мои начальные взгляды состояли в том, что, вероятно, было бы некоторое преимущество для обязательных классов как одиночные элементы, если бы я ожидал, что они будут использоваться справедливо часто. Это просто означает, что существует намного меньше newпродолжение луга, особенно когда объект Вы создаете, заканчивает тем, что имело большое дерево зависимостей. В значительной степени единственные нестатические поля на любом из этих классов являются теми значениями, вводимыми в конструктора, таким образом, существует относительно мало памяти наверху к имению в наличии экземпляра, когда это не используется.

Затем я считал "Singleton, я люблю Вас, но Вы побеждаете меня" на www.codingwithoutcomments.com, и она заставила меня задаться вопросом, имел ли я верное представление. В конце концов, Ninject компилирует функции создания объекта по умолчанию, таким образом, существует очень мало отражения, наверху вовлеченного в создание дополнительных экземпляров этих объектов. Поскольку мы не допускаем бизнес-логику в конструктора, создание новых экземпляров является действительно легкой операцией. И объекты не имеют набора нестатических полей, таким образом, нет большой памяти, наверху вовлеченной в создание новых экземпляров, также.

Таким образом в этой точке, я начинаю думать, что она, вероятно, не будет иметь значения очень так или иначе. Есть ли дополнительные соображения, которые я не принял во внимание? Кто-либо на самом деле испытал существенное улучшение в производительности путем изменения жизненных циклов определенных типов объектов? Следует DI копируют единственную реальную важную вещь или там другие причины, что использование единственного экземпляра объекта может быть по сути "плохим?"