Как определить поведение объекта через web.config?

Question

Я хочу иметь возможность определить в моем файле web.config тип соединения, который мой объект будет использовать для получения данных (переменных) (из XML или из баз данных).

Я хотя и об использовании паттерна Стратегии, но я несколько застрял из-за необходимости написать где-то имя класса, которое мне не нужно.

Есть предложения?

Дополнительная информация

У меня есть интерфейс IContext .Он реализован в ContextXML и ContextDB .

У меня есть класс Context , в котором есть IContext член (называемый _context ).

Класс Context читает (через ContextConfiguration ) app.config .

Я хочу _context чтобы иметь возможность быть ContextXML или ContextDB ... или ContextJSon или любым другим новым классом, который реализует IContext ,

Answer 1

Задумывались ли вы о создании класса ContextManager и использовании "конфигурации по соглашению"?

То, что я бы сделал, это добавление члена getName к вашему IContext интерфейсу - это просто возвращает красивую понятную человеку строку для каждой реализации - так же просто, как "ContextXML" для вашего ContextXML класса.

Когда ваш ContextManager (возможно, Singleton, BTW) запускается, он сканирует известный каталог для реализаций IContext, создавая их экземпляры с помощью отражения (или какого-либо другого механизма, который яЯ не знаком с VB.Net, но я уверен, что есть способ и помещаю их в коллекцию.

Теперь, когда вы создаете Context объектов, вы можете попросить у ContextManagerподходящий IContext - либо явно [например, getIContextByName("ContextDB")], либо с более простым методом, который просто возвращает то, что было сконфигурировано каким-либо другим механизмом - то есть набор методов примерно такой:

• getPossibleIContextImplementationNames()
• setCurrentIContextImplementation({name})
• getCurrentIContext()

Как и в стороне, вы застряли с этим наименованием?Потому что наличие Context объекта, который использует и IContext, кажется немного необычным.Если ваши IContext реализации фактически используются для получения данных откуда-то, почему бы не вызвать интерфейс IDAO или IDataAccessor?