Почему Вы хотели бы Внедрение зависимости без конфигурации?
Вы можете создать результирующий массив объекта на основе чисел как index = number-1
var nums = [2,3,1];
var objects = [
{firstName:"John", lastName:"Doe", age:28, eyeColor:"blue"},
{firstName:"Jane", lastName:"Doe", age:22, eyeColor:"brown"},
{firstName:"Jack", lastName:"Doe", age:50, eyeColor:"red"}
];
var sortedObjects = nums.map(function(num) {return objects[num-1]});
sortedObjects.forEach(function(obj, i) {some_function(nums[i], obj)})
9 ответов
Я не думаю, что Вы хотите платформу DI без конфигурации. Я думаю, что Вы хотите платформу DI с конфигурацией, в которой Вы нуждаетесь.
Я займу пружину в качестве примера. Назад в "былые времена" мы раньше помещали все в XML-файлы для создания всего настраивающимся.
При переключении на полностью аннотируемый режим Вы в основном определяете, какие роли компонента yor приложение содержит. Таким образом, данный сервис может, например, иметь одну реализацию, которая является для "регулярного времени выполнения", где существует другая реализация, которая принадлежит "Заблокированной" версии приложения. Кроме того, при проводном соединении для интеграционных тестов можно использовать третью реализацию.
При рассмотрении проблемы таким образом Вы быстро понимаете, что большинство приложений только содержит очень ограниченный набор ролей компонента во времени выполнения - это вещи, которые на самом деле заставляют различные версии компонента использоваться. И обычно данная реализация компонента всегда связывается с этой ролью; это - действительно причина существования той реализации.
Таким образом, если Вы позволяете "конфигурации" просто указать, каких ролей компонента Вы требуете, можно уйти без намного большего количества конфигурации вообще. Конечно, там всегда будет исключениями, но затем Вы просто обрабатываете исключения вместо этого.
Я нахожусь на пути с krosenvold, здесь, только с меньшим количеством текста: В рамках большинства приложений у Вас есть точно одна реализация на необходимый "сервис". Мы просто не пишем приложения, где каждому объекту нужны 10 или больше реализаций каждого сервиса. Таким образом, имело бы смысл иметь простой путь, говорят, что "это - реализация по умолчанию, 99% всех объектов с помощью этого сервиса будут довольны им".
В тестах Вы обычно используете определенный макет, таким образом, никакая потребность в любой конфигурации там любой (так как Вы делаете проводное соединение вручную).
Это - то, о чем конвенция по конфигурации - все. Большую часть времени конфигурация является просто повторением дампа чего-то, что платформа DI уже должна знать :)
В моих приложениях я использую объект класса в качестве ключа для поиска реализаций, и "ключ", оказывается, реализация по умолчанию. Если моя платформа DI не может найти переопределение в конфигурации, она просто попытается инстанцировать ключа. С более чем 1 000 "сервисов" мне нужны четыре переопределения. Это было бы большим количеством бесполезных XML для записи.
С внедрением зависимости модульные тесты становятся очень простыми настроить, потому что можно ввести насмешки вместо реальных объектов в объекте под тестом. Вы не нуждаетесь в конфигурации для этого, просто создаете, и вводит насмешки в коде модульного теста.
Я получил этот комментарий к моему блогу от Nate Kohari:
Довольный Вы рассматриваете использование Ninject! Ninject занимает позицию, что конфигурация Вашей платформы DI является на самом деле частью Вашего приложения и не должна публично настраиваться. Если Вы хотите, чтобы определенная привязка настраивалась, можно легко заставить модули Ninject считать app.config. Наличие Вашей привязки в коде сохраняет Вас от многословия XML и дает Вам безопасность типов, перефакторизуемость и intellisense.
Вы не должны даже использовать платформу DI для применения шаблона внедрения зависимости. можно просто использовать статические методы фабрики для создания объектов, если Вам не нужна конфигурируемость кроме перекомпиляции кода.
таким образом, все это зависит от того, как настраивающийся Вы хотите, чтобы Ваше приложение было. если Вы захотите, чтобы это было настраиваемым/сменным без перекомпиляции кода, то Вы захотите что-то, что можно настроить через текстовые файлы или XML-файлы.
Я буду второй использование DI для тестирования. Я только действительно рассматриваю использование DI в данный момент для тестирования, поскольку наше приложение не требует никакой основанной на конфигурации гибкости - это является также слишком большим для рассмотрения в данный момент.
DI имеет тенденцию приводить к инструменту для очистки, более разделенному дизайну - и это дает преимущества повсюду вокруг.
Если Вы захотите изменить поведение после сборки конечных версий, то Вам будет нужна платформа DI, которая поддерживает внешние конфигурации, да.
Но я могу думать о других сценариях, в которых эта конфигурация не необходима: например, управляйте инжекцией компонентов в Вашей бизнес-логике. Или используйте платформу DI для создания поблочного тестирования легче.
Необходимо читать о ПРИЗМЕ в.NET (это - лучшие практики, чтобы сделать составные приложения в.NET). В этих лучших практиках каждый модуль "Выставляют" их тип реализации в общем контейнере. Таким образом, каждый модуль имеет ясные обязанности по, "кто обеспечивает реализацию для этого интерфейса". Я думаю, что будет достаточно ясно, когда Вы поймете как работа ПРИЗМЫ.
При использовании инверсии управления, Вы помогаете заставить свой класс сделать как можно меньше. Скажем, у Вас есть некоторый сервис окон, который ожидает файлов и затем выполняет ряд процессов на файле. Один из процессов должен преобразовать его в ZIP, который это затем посылает ему по электронной почте.
public class ZipProcessor : IFileProcessor
{
IZipService ZipService;
IEmailService EmailService;
public void Process(string fileName)
{
ZipService.Zip(fileName, Path.ChangeFileExtension(fileName, ".zip"));
EmailService.SendEmailTo(................);
}
}
Почему этот класс должен был бы на самом деле сделать архивирование и пользование электронной почтой, когда Вы, возможно, выделили классы, чтобы сделать это для Вас? Очевидно, Вы не были бы, но это - только вывод до моей точки :-)
В дополнение к не реализации Zip и электронной почты, почему класс должен знать, какой класс реализует сервис? Если Вы передаете интерфейсы конструктору этого процессора затем, он никогда не должен создавать экземпляр определенного класса, ему дают все, что он должен сделать задание.
Используя D.I.C. можно настроить, какие классы реализуют определенные интерфейсы и затем просто заставляют его создавать экземпляр для Вас, он введет зависимости в класс.
var processor = Container.Resolve<ZipProcessor>();
Таким образом, теперь не только имеют, Вы чисто разделили функциональность класса от общей функциональности, но Вы также препятствовали тому, чтобы потребитель/поставщик имел любые явно заданные знания друг друга. Это делает код чтения легче понять, потому что существует меньше факторов для рассмотрения одновременно.
Наконец, когда поблочное тестирование можно передать в дразнивших зависимостях. При тестировании ZipProcessor дразнившие сервисы будут просто утверждать, что класс попытался послать электронное письмо, а не его действительно пытающийся отправить тот.
//Mock the ZIP
var mockZipService = MockRepository.GenerateMock<IZipService>();
mockZipService.Expect(x => x.Zip("Hello.xml", "Hello.zip"));
//Mock the email send
var mockEmailService = MockRepository.GenerateMock<IEmailService>();
mockEmailService.Expect(x => x.SendEmailTo(.................);
//Test the processor
var testSubject = new ZipProcessor(mockZipService, mockEmailService);
testSubject.Process("Hello.xml");
//Assert it used the services in the correct way
mockZipService.VerifyAlLExpectations();
mockEmailService.VerifyAllExceptions();
Так короче говоря. Вы хотели бы сделать это к 01: Препятствуйте тому, чтобы потребители знали явно, какой поставщик реализует сервисы, в которых это нуждается, что означает, что существует меньше для понимания сразу, когда Вы читаете код. 02: Сделайте поблочное тестирование легче.
Pete