Создал специальный вспомогательный класс для соединения и работы с БД.
Целесообразно ли использовать подобный класс, если нет необходимости или опыта работы с Entity Framework
. Прошу указать на недочеты и сделать прочие замечания.
Сам класс:
public class DBHelper
{
public static string sqlConnectionString = "Data Source=<default>;Initial Catalog=<default>;Persist Security Info=<default>;User ID=<default>;Password=<default>";
public bool connectionOnline = false;
public SqlConnection sqlConnection = null;
public DBHelper(string _DataSource, string _InitialCatalog, string _User, string _Password)
{
string AssebledConnectionString =
"Data Source=" + _DataSource + ";" +
"Initial Catalog=" + _InitialCatalog + ";" +
"Persist Security Info=True;" +
"User ID=" + _User + ";" +
"Password=" + _Password;
connectionOnline = false;
InitializeConnection(AssebledConnectionString);
}
public DBHelper()
{
connectionOnline = false;
InitializeConnection(sqlConnectionString);
}
public DBHelper(string sqlCustomConnectionString = null)
{
connectionOnline = false;
InitializeConnection(sqlCustomConnectionString);
}
public void Dispose()
{
this.DisengageConnection();
sqlConnection = null;
}
void InitializeConnection(string sqlCustomConnectionString = null)
{
try
{
if ((connectionOnline) || (sqlConnection != null)) return;
sqlConnection = new SqlConnection(sqlCustomConnectionString ?? sqlConnectionString);
sqlConnection.Open();
connectionOnline = true;
}
catch
{
connectionOnline = false;
//Не удалось соединиться с базой данных
}
}
void DisengageConnection()
{
if ((!connectionOnline) || (sqlConnection == null)) return;
sqlConnection.Close();
connectionOnline = false;
}
public SqlCommand GetStoredProc(string procedureName)
{
SqlCommand sqlCommand = new SqlCommand(procedureName, sqlConnection)
{
CommandType = CommandType.StoredProcedure
};
return sqlCommand;
}
public DataSet GetDataSet(SqlCommand sqlCommand)
{
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(sqlCommand);
DataSet dsTable = new DataSet();
sqlDataAdapter.Fill(dsTable);
return dsTable;
}
public DataTable GetResultTable(SqlCommand sqlCommand, int dataTableNumber = 0)
{
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(sqlCommand);
DataSet dsTable = new DataSet();
sqlDataAdapter.Fill(dsTable);
if ((dsTable.Tables.Count > 0) && (dsTable.Tables.Count - 1 >= dataTableNumber))
{
return dsTable.Tables[dataTableNumber];
}
else
{
return new DataTable();
}
}
}
Пример использования хранимой процедуры:
DBHelper db = new DBHelper();
SqlCommand sqlCommand = db.GetStoredProc("<имя хранимой процедуры>");
sqlCommand.Parameters.AddWithValue("@<имя параметра 1>",<param1_value>);
sqlCommand.Parameters.AddWithValue("@<имя параметра 2>",<param2_value>);
//...
sqlCommand.Parameters.AddWithValue("@<имя параметра N>",<paramN_value>);
//далее действия в зависимости от характера хранимой процедуры
//либо простое исполнение
sqlCommand.ExecuteNonQuery();
//либо получение данных
DataTable dataTable = db.GetResultTable(sqlCommand);
Целесообразно ли использовать подобный класс, если нет необходимости или опыта работы с Entity Framework.
Подобные классы можно использовать если нет возможности работы с Entity Framework (например, Вам достался древний проект) или проект совсем совсем простой. Хотя в последнем случае это весьма спорно.
Что касается отсутствия опыта, в качестве довода к использованию подобных решений, то это и вовсе ни о чём. Entity Framework, при наличии познаний в области C# и СУБД, достаточно легко освоить самостоятельно.
Что касается самого класса, крайне желательно:
По сути Ваш класс только создаёт подключение и предоставляет доступ к низкоуровневым объектам на его основе. Таким образом даже в Вашем примере почти всю работу нужно всё равно делать руками.
Поэтому нужно либо упростить вызовы методов так чтобы они только на основе имени объекта БД и его параметров возвращали готовый результат сразу, без дополнительных действий. Либо написать класс обёртку наподобие репозитория, который будет решать низкоуровневые задачи.
MS SQL это само по себе не плохо. Только, если не ошибаюсь, он никогда не был единственной СУБД для .NET. Кроме того, если раньше он, возможно, и мог претендовать на роль своего рода промышленного стандарта, то сейчас ситуация сильно изменилась. Очень многие проекты на C# используют СУБД не от MS и даже не от Oracle (к примеру, PostgreSQL).
Поэтому узкая специализация фреймворка для работы с СУБД (раз уж Вы решились по сути написать свой) хотя и может оказаться преимуществом в "профильных" проектах, но в целом его применение этими проектами и будет ограничено.
Айфон мало держит заряд, разбираемся с проблемой вместе с AppLab
Прошу помощи в разработке программы, оригинал на паскале написан и на 32/64 не переписать его и не запустить (досбоксы и тому подобное не подходит)Надо...
Ошибка в запросe (1054): Unknown column 'gRomNo' in 'field list'
Пытаюсь написать скрипт, который реализует удаленный вход на mysql сервер и делает там запрос, затем выводит это все в файл, но при запуске скрипта...