Какие стратегии позволяют использовать контейнер IoC в библиотеке? [closed]

Closed . Этот вопрос основан на мнении . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы на него можно было ответить с помощью фактов и цитат, редактируя это сообщение .

Закрыт в прошлом году .

Более короткая версия остальной части вопроса: у меня проблема, и контейнер IoC - это инструмент. Проблема кажется чем-то, что IoC может решить, но я не прочитал достаточно инструкций инструмента, чтобы знать наверняка. Мне любопытно, выбрал ли я не тот инструмент или к какой главе инструкции можно было бы пропустить, чтобы получить помощь.

Я работаю над библиотекой элементов управления Windows Forms. В прошлом году я столкнулся с модульным тестированием и увлекся улучшением качества наших автоматических тестов. Тестировать элементы управления сложно, и в Интернете мало информации об этом. Одна из неприятных вещей - это отделение логики взаимодействия от связующего элемента пользовательского интерфейса, который вызывает ее, что приводит к тому, что каждый элемент управления имеет на несколько больше зависимостей, чем я обычно считаю здоровым для класса. Создание подделок для этих элементов при тестировании их интеграции с элементом управления довольно утомительно, и я ищу решение в IoC.

Есть одно препятствие, которое я не знаю, как преодолеть. Чтобы настроить контейнер, вам нужен код загрузчика, который запускается перед остальной частью приложения. В приложении для этого есть очень четкое место. В библиотеке все не так ясно.

Первое решение, которое приходит на ум, - это создание класса, который предоставляет статический экземпляр контейнера и устанавливает контейнер в его инициализаторе типа. Это будет работать во время выполнения, но в тестовой среде я не уверен, насколько хорошо это будет работать. Тесты могут выполняться параллельно, и многие тесты потребуют разных зависимостей, поэтому статическое общее состояние будет кошмаром. Это наводит меня на мысль, что создание контейнера должно быть методом экземпляра, но тогда у меня возникает проблема с курицей и яйцом, поскольку элемент управления должен создать свой контейнер, прежде чем он сможет создать себя. На ум приходит инициализатор типа элемента управления, но мои тесты не смогут изменить это поведение. Это заставило меня подумать о том, чтобы сделать сам контейнер зависимостью от элемента управления, где видимые пользователю конструкторы обеспечивают реализацию по умолчанию во время выполнения, но это оставляет на усмотрение моих тестов настраивать свои собственные контейнеры. Я не особо задумывался об этом, но похоже, что это будет на том же уровне усилий, что и то, что у меня есть сейчас: тесты, которые должны инициализировать 3-5 зависимостей на тест.

Обычно я бы много пробовал самостоятельно, чтобы увидеть, что болит. У меня сейчас очень жесткие дедлайны, поэтому у меня не так много времени на эксперименты, когда я пишу код; У меня есть только короткие моменты, чтобы подумать об этом, и я мало что изложил. Я уверен, что у кого-то была похожая проблема, поэтому было бы хорошо, если бы мне не пришлось изобретать велосипед.

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

Обновление:

Я хотел бы ответить на ответ Марка Симана, но для этого потребуется больше символов, чем позволяет поле комментария .

Я уже играю с шаблонами презентационных моделей. Представление в этом случае - это общедоступный класс управления, и каждый имеет один или несколько классов контроллеров. Когда в элементе управления запускается какое-либо событие пользовательского интерфейса, единственная логика, которую он выполняет, - это решение, какие методы контроллера необходимо вызвать.

Краткое выражение исследования этой конструкции - мои классы контроллеров тесно связаны со своими представлениями. Основываясь на утверждении, что контейнеры DI работают со слабосвязанным кодом, я читаю «неправильный инструмент для работы». Возможно, я смогу разработать более слабосвязанную архитектуру, и тогда DI-контейнер станет проще в использовании. Но это потребует значительных усилий, и это будет полная переработка поставляемого кода; Мне придется поэкспериментировать с новыми вещами, прежде чем ходить на цыпочках вокруг старых. Это вопрос другого дня.

Почему я вообще хочу внедрять сильно связанные типы, а не использовать локальные значения по умолчанию? Некоторые из швов предназначены для расширяемости для опытных пользователей. Мне нужно протестировать различные сценарии с неправильными реализациями, а также проверить, выполняю ли я свои контракты; фиктивные объекты отлично подходят.

Для текущего дизайна предложение Криса Балларда о «бедном человеке» s просто много утомительной настройки. У меня было видение, что я смогу вложить всю эту скуку в какой-нибудь метод установки контейнера DI, но чем больше я пытаюсь оправдать такой подход, тем больше убеждаюсь, что пытаюсь вешать картинки кувалдой.

Я подожду 24 часа или около того, чтобы посмотреть, продвинется ли обсуждение дальше, прежде чем принять.

c# testing inversion-of-control

задан OwenP 1 April 2011 в 18:26

0 ответов

Другие вопросы по тегам:

c# testing inversion-of-control

Какие стратегии позволяют использовать контейнер IoC в библиотеке? [closed]

0 ответов

Похожие вопросы: