Подскажите, как лучше оформить класс

В общем, хочу сделать класс, который будет импортировать DataTable в Access или MS SQL.
Класс будет иметь 1 метод: Append, которому на вход будет подаваться DataTable, а метод в свою очередь будет загружать DataTable в нужный пункт назначения.
Разумеется, внутренняя логика Append у Access может сильно отличаться, например:
В Access нужно следить за тем, что бы файл не был выше 2гб, иначе бд поломается В MS SQL можно воспользоваться BulkCopy, а в Access потребуется какой-то самопал.
Соответственно и конструкторы могут сильно отличаться по параметрам, например:
Строки подключения между двумя типами будут отличаться В MS SQL можно использовать или не использовать транзакцию В Access можно восстанавливать или не восстанавливать БД после каждого Append.
Как лучше всего все это оформить?
UPD:
Есть у меня некоторые предположения, как это можно сделать, но не знаю на сколько это верно.
Сделать интерфейс:
public interface IApend { void Append(DataTable dt); }
Реализовать его в 2 ух классах, каждый из которых будет содержать в себе собственную логику импорта:
public class ImporterToSQL: IApend { //Какие-то поля public void Append(DataTable dt) { //Какая-то логика } } public class ImporterAccess : IApend { //Какие-то поля public void Append(DataTable dt) { //Какая-то логика } }
И создать такой класс:
public class Importer { IApend Concrete;
public Importer(IApend concrete) { Concrete = concrete; } static Importer ImporterToSQL(object v,object v2,object v3) { return new Importer(new ImporterToSQL(object v, object v2, object v3)); } static Importer ImporterToSQL(object v, object v2) { return new Importer(new ImporterToSQL(object v, object v2)); } static Importer ImporterToAccess(object v, object v2, object v3) { return new Importer(new ImporterAccess(object v, object v2, object v3))); } static Importer ImporterToAccess(object v, object v2) { return new Importer(new ImporterAccess(object v, object v2)); } public void Append(DataTable dt) { Concrete.Append(dt); } }
На сколько это верно и на сколько хорошо этот подход будет работать в плане добавления нового функционала(Например, мне приспичило добавить импорт из SQL в Access)? Это , вроде, зовется фабрикой классов?

Ответ

Вы на правильном пути. Общий интерфейс для конвертации -- это правильно. Только я бы назвал его чуть поконкретнее, хотя б IImporter какой-нибудь.
Что касается создания конкретных экземпляров и вашего класса Importer. Для создания действительно нужна фабрика. Однако она у вас получилась не в чистом виде. Смысла оборачивать экземпляр в ваш Importer нет -- у вас уже есть интерфейс. Просто создавайте нужные экземпляры и возвращайте их. А клиент уже будет вызывать напрямую методы:
public static class ImporterFactory { static IImporter CreateSQLImporter(object v, object v2, object v3) { return new ImporterToSQL(v, v2, v3); }
static IImporter CreateAccessImporter(object v, object v2, object v3) { return new ImporterAccess(v, v2, v3); }
// и так далее }
В качестве параметров для конструкторов у вас наверняка выступают специфичные для каждой реализации данные: например, строка подключения для SQL и путь к mdb файлу для Access. В идеале клиент вообще не должен знать что-то о деталях реализации, а фабрика должна содержать один метод на тип. Все детали о реализации прячутся в фабрике, которая подсовывает нужные параметры напрямую из конфигурации (например, из app.config). При этом клиент вообще ничего не будет знать о реализации:
public static class ImporterFactory { static IImporter CreateImporter(object v) { var generalConfig = GetGeneralConfig(); if (generalConfig.Type == "sql") { var config = GetSqlImporterConfig(); return new ImporterToSQL(config.ConnectionString, v); } else if (generalConfig.Type == "access") { var config = GetAccessImporterConfig(); return new ImporterToAccess(config.ConnectionString, v); } } }
Такой подход будет очень хорошо работать, если вам потребуется импорт в новое место. Вы просто напишете еще одну реализацию IImporter, внести изменения в ImporterFactory и все. Все клиентs, которые используют IImporter, менять не придется. В случае же отдельных методов вам придется менять вызывающий код, который управляет тем, какой метод вызвать.

Что касается импорта из SQL в Access, то такую задачу описанным выше способом не решить. Выше мы рассмотрели только задачу "как данные, представленные в универсальном виде (DataTable), записать в конкретное место". Задачу импорта из SQL в Access можно переформулировать как "как извлечь данные из одного места и записать их в другое место". Такую задачу полезно разбить на два шага и ввести промежуточный этап. Какой? Правильно, получение данных в универсальном виде. Таким образом, шага будет два:
Импорт из источника с преобразованием в универсальный вид Экспорт в другое место
Соответственно, два основных контракта будут выглядеть как-то так:
interface IImporter { DataTable Import(); }
interface IExporter { void Export(DataTable data); }
Реализация второго шага у вас уже есть, правда сейчас она называется импортом. При наличии двух шагов будет логичнее назвать их с т.з. того, как данные движутся относительно вашего приложения. Вы импортируете (загружаете) данные из одного источника и экспортируете (выгружаете) их в другое место.
Реализация первого шага будет аналогична -- различные реализации интерфейсов, фабрика.
Для осуществления процесса конвертации вам понадобится некоторая общая сущность, которая будет соединять шаги. Она может принимать в качестве зависимостей как фабрики, так и экземпляры импортера/экспортера:
public class DataConverter // придумайте имя поудачнее, пожалуйста :) { private readonly IImporter _importer; private readonly IExporter _exporter;
public DataConverter(IImporter importer, IExporter exporter) { _importer = importer; _exporter = exporter; }
public void Convert() { var data = _importer.Import(); _exporter.Export(data); } }