C++: Общий дизайн интерфейса для базы данных

Question

У меня есть класс, который используется для создания соединения с базой данных:

class DBHandler 
{ 
public: 
    DBHandler(); 
    ~DBHandler(); 

    int connect(); 
    int execQuery(string query); 
    string getField(int row, int col); 
}; 

Теперь есть еще один класс, который используется для извлечения некоторой информации из базы данных,

class DBManager 
{ 
public: 
    DBManager(); 
    ~DBManager(); 

    //Approach 1 
    string getUsername() 
    { 
     //create a query here and use  object of DBHandler class to execute it. 
    } 

    //Approach 2 
    string getUsername (struct  QueryDetails& qDetails) 
    { 
     //create query using fields of structure and execute the query using DBHandler class. 
    } 
}; 

Теперь вот проблема:

1), какой подход я должен следовать:

• A) Если я использую подход 1, мне нужен жесткий код запроса.
• B) Если я использую подход 2, мне нужно заполнить структуру каждый раз перед вызовом функции getUsername.

2) Есть ли лучшее решение, кроме этих двух, которые были бы общими?

PS: Определение структуры

struct QueryDetails 
{ 
    string tableName; 
    vector<string> colList; 
... 
}; 

Answer 1

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

Ваш подход 1 имеет следующие преимущества:

• это надежный и безопасный подход: Запросы написаны со знанием соответствующего объекта
• , если база данных эволюционировать легко узнать (текст поиск), где конкретные запросы сделаны для таблиц, и обновил код запрашивая для объекта
• если ваш объект развивается, само собой разумеется, что вы сразу понимаете, что вы должны изменить на стороне базы данных

Главное неудобство заключается в том, что вы тесно связаны с базой данных. Если завтра вы перейдете от PostGres к чему-то еще, вы должны переписать каждый запрос.

Ваш подход 2 имеет следующие преимущества:

• Это очень гибкий
• Если изменение базы данных, вы должны изменить только общие функции.

Неудобство в том, что эта гибкость несет много рисков для обслуживания: вы не можете быть уверены, что правильный запрос отправляется клиентом, а оценка воздействия изменений макета базы данных очень трудно оценить.

Итак, вам решать, какой из них больше подойдет вашим потребностям.

Я лично склоняюсь к 1. Но это субъективно, и я бы в любом случае представил дополнительный слой, чтобы сделать код приложения более независимым от системы баз данных, которая реализует доступ к базе данных.

Однако, в зависимости от вашей потребности, большая гибкость может быть полезной.Например, если ваш класс на самом деле должен быть средним уровнем для других calsses для извлечения своих собственных данных, то подход 2 может быть лучшим вариантом.