У меня есть слой доступа к данным ADO.NET, который был написан для работы с несколькими поставщиками данных, и обнаружил, что не могу сделать некоторые операции полностью независимыми от поставщика данных.
Как часть функции установки моего приложения, он сообщает DAL о создании базы данных с таблицей и некоторыми данными. DAL использует команду Sql CREATE DATABASE. Теперь это нормально для SQL Server, но при использовании SQLite этап создания базы данных не требуется, поскольку источника данных, указанного в строке подключения, достаточно для определения используемой базы данных.
В настоящее время я планирую справиться с этим, написав класс DatabaseCreator с виртуальным методом createDatabase, который я могу создать подклассом для конкретных поставщиков данных, и у меня есть фабрика, которая обслуживает конкретный DatabaseCreator на основе используемого поставщика данных. или по умолчанию.
Проблема с этим подходом состоит в том, что мое приложение не будет "просто работать" с новыми поставщиками данных, которые не совместимы со стандартным способом создания базы данных, но потребует нового выпуска с новым DatabaseCreator для нового поставщик данных.
Единственный способ обойти эту проблему, который я вижу, состоит в том, чтобы позволить моему приложению быть настроенным с помощью DatabaseCreator для использования аналогично тому, как оно сконфигурировано с поставщиком данных, то есть DatabaseCreator может быть предоставлен в отдельной сборке.
Я новичок в ADO.NET, поэтому не уверен, насколько распространена проблема такого типа при попытке написать независимые от поставщика данных приложения.
Существует ли поддержка такого подхода в ADO.NET?
например. Поставляемые поставщиком или сторонние существующие библиотеки, определяющие интерфейсы и / или реализации вспомогательных классов для общих операций, реализации которых могут зависеть от поставщика данных?
В качестве альтернативы, есть ли лучший способ сделать это?