Там какая-либо причина не состоит в том, чтобы использовать мой МОК в качестве общего Репозитория Настроек?
Я новичок в python, и я уже думал, что я слишком глуп, чтобы воспроизвести самые простые предложения, сделанные здесь. Оказывается, есть ошибка, которую нужно знать:
Когда скрипт python выполняется из IDLE, некоторые IO-команды, похоже, ведут себя совершенно по-другому (поскольку на самом деле нет окна терминала).
Например. msvcrt.getch не блокирует и всегда возвращает $ ff. Об этом уже сообщалось давно (см., Например, https://bugs.python.org/issue9290 ) - и он отмечен как фиксированный, так как проблема, похоже, сохраняется в текущих версиях python / IDLE.
Итак, если какой-либо из вышеперечисленного кода не работает для вас, попробуйте запустить скрипт вручную, а НЕ с IDLE.
4 ответа
IoC.Container. Твердость ("default_uom");
Я рассматриваю это как классический антишаблон, где Вы используете контейнер МОК как услуга локатор - ключевые вопросы, которые результат:
- Ваше приложение больше не перестало работать быстро, если Ваш контейнер будет неправильно сконфигурирован (то Вы будете только знать об этом в первый раз, когда это пытается разрешить, что конкретный сервис в коде, который не мог бы произойти за исключением определенного набора логики/обстоятельств).
- Тяжелее для тестирования - не невозможный, конечно, но Вы любой должен создать реальное (и полунастроенный) экземпляр виндзорского контейнера для Ваших тестов или ввести одиночный элемент с насмешкой для IWindsorContainer - это добавляет большое трение к тестированию, по сравнению только с способностью передать ложные/тупиковые сервисы непосредственно в Ваш класс под тестом через конструкторов/свойства.
- Тяжелее для поддержания этого вида приложения (конфигурация не централизована в одном месте),
- Нарушает много других принципов разработки программного обеспечения (DRY, SOC и т.д.)
Касающаяся часть Вашего исходного оператора является импликацией, что большинство Ваших классов будет иметь зависимость от Вашего одиночного элемента МОК - если они получат все сервисы, введенные на пути, конструкторы/зависимости, затем имеющие некоторое плотное соединение с МОК, должны быть исключением из правила - В целом единственное время, я беру зависимость от контейнера, когда я делаю что-то хитрое т.е. стараюсь избегать круговой зависимости проблемы или желание создать компоненты во времени выполнения по некоторым причинам, и даже затем я могу часто стараться не брать зависимость от чего-либо больше затем, что универсальный интерфейс IServiceProvider, позволяя мне загрузить дом - печет реализацию локатора МОК или службы, если я должен снова использовать компоненты в среде за пределами исходного проекта.
У меня обычно нет многих классов в зависимости от моего контейнера МОК. Я обычно пытаюсь перенестись, материал МОК в фасаде возражают, что я ввожу в другие классы, обычно большая часть моей инжекции МОК сделана только в более высоких слоях моего приложения все же.
Если Вы делаете вещи Вашим путем, Вы не можете протестировать MyClass, не создавая конфигурацию МОК для Ваших тестов. Это сделает Ваши тесты тяжелее для поддержания.
Другая проблема состоит в том, что Вы собираетесь иметь powerusers своего программного обеспечения, кто хочет изменить конфигурацию, редактируя Ваши файлы конфигурации МОК. Это - что-то, чего я хотел бы избежать. Вы могли разделить свою конфигурацию МОК на нормальный файл конфигурации и МОК определенный материал. Но затем Вы могли точно также использовать нормальную функциональность конфигурации .NET для чтения конфигурации.
Прокомментировать Ваш определенный пример:
public class MyClass {
public MyClass(IDataSource ds) {
UnitOfMeasure duom = IoC.Container.Resolve<UnitOfMeasure>("default_uom");
}
}
Это мешает снова использовать Ваш класс. Более конкретно это мешает инстанцировать Вашего класса за пределами узкого шаблона использования, которым Вы ограничиваете его. Одно из наиболее распространенных мест, которые это проявит само, при попытке протестировать класс. Намного легче протестировать тот класс, если UnitOfMeasure может быть передан конструктору непосредственно.
Кроме того, Ваш выбор названия экземпляра UOM ("default_uom") подразумевает, что значение могло быть переопределено, в зависимости от использования класса. В этом случае Вы не хотели бы к "твердому коду" значение в конструкторе как этот.
Используя конструктора шаблон инжекции не делает Ваш класс зависящим от МОК, совсем противоположное, это дает клиентам опцию использовать МОК или нет.
Да, многие мои классы заканчиваются с зависимостью от IoC.Container, но это - зависимость, которую большинство моих классов будет иметь так или иначе.
Я думаю, что это - затруднение проблемы. Если на самом деле большинство Ваших классов связано с самим контейнером МОК, возможности - Вы, должен заново продумать Ваш дизайн.
Вообще говоря, Ваше приложение должно только относиться к контейнерному классу непосредственно однажды во время начальной загрузки. После того, как у Вас есть тот первый рычаг в контейнерную остальную часть графа объектов, должен полностью управляться контейнером, и все те объекты должны не обращать внимания на то, что они были созданы контейнером МОК.