Уровень Database разрабатывает вопрос
Я разрабатывал слой доступа к базе данных, который позволяет нам поддерживать несколько баз данных в наших программах. В конце пользователи наших программ должны смочь выбрать базовую систему баз данных из диапазона систем баз данных. Некоторые маленькие клиенты могли бы быть довольны Доступом MS, другие предпочитают MySql, других DB2. Те системы дб - те, я хочу быть нацеленным на данный момент.
Учитывая те требования, я придумал абстрактный класс DatabaseConnection. Внутренне, я использую Систему. Данные. Распространенный. Данные. DbConnection-класс, который уже дает мне некоторую гибкость.
Вещи, которые должны забетонировать экземпляры (OleDbCommand вместо DbCommand, например) скрыты в абстрактных методах как CreateDbCommand (). Подклассы (как AccessDbConnection) реализуют их и обеспечивают конкретные экземпляры. В настоящее время это приводит к этой иерархии (имена классов, сокращенные для удобочитаемости):
DatabaseConnection / | \ AccessConn MySqlConn DB2Conn
Однако существует несколько операций, которые характерны для базовой системы баз данных, таковы как получение всех имен таблиц. Чувствует себя неправильным поместить абстрактный метод, GetTableNames () в DatabaseConnection-класс и иметь подклассы перезаписывают его.
Я думал, возможно, что я могу создать другой абстрактный базовый класс под названием DatabaseTools, объявить, что те операции тут же реализуют их в подклассах, которые напоминают подклассы класса DatabaseConnection. Что означает, что для AccessDbConnection, у меня также был бы класс AccessTools и т.д. и т.д.:
DatabaseConnection DatabaseTools / | \ / | \ AccessConn MySqlConn DB2Conn AccessTools MySqlTools DB2Tools
Так или иначе я действительно не взволнован этой идеей.
Какие идеи необходимо решить эту проблему проектирования?
Заранее спасибо в течение Вашего времени и ответов :)
Удачи
Христианин
3 ответа
Поскольку вы не получите очков за 100% чистоту ОО, следуйте совету Swingline Rage. Вы также можете сделать его чистым, просто переименовав класс ;-)
Единственное, если вы используете интерфейсы вместо абстрактных классов и наследования, у вас меньше шансов обжечься. Интерфейсы могут наследоваться друг от друга, но, скорее всего, вам это не понадобится. Их немного сложнее писать, но вы можете использовать их точно так же.
http://www.codeproject.com/KB/cs/abstractsvsinterfaces.aspx
Интерфейс или абстрактный класс: что использовать?
"А как насчет общего кода в базовом классе?". - Вы можете оставаться DRY, если будете использовать статические классы и вызывать их (не грех использовать некоторые процедурные техники в ОО). Q#2 в теме stack overflow выше выглядит интересно, но я не могу за него поручиться.
Вместо абстрактного метода, почему бы не реализовать метод, который извлекает имена таблиц с использованием представлений стандарта ANSI INFORMATION_SCHEMA , а затем просто переопределить его в реализации DatabaseConnection для поставщика, который не соответствует стандарту ANSI?
Кроме того, я не вижу ничего плохого в подходе абстрактного метода с точки зрения дизайна.
На мой взгляд, определение операций с базами данных в отдельной иерархии - лучшая идея. Я бы предпочел инкапсулировать инструменты внутри конкретных объектов соединений, а затем получать соединения через одну фабрику.
Точнее, чтобы выполнить задачу по получению имен всех таблиц, вызов будет выглядеть так:
ConnectionFactory(ACSESS).getConnection().getTools().fetchSchema();