We Keep Coding

Access different SQL Server Types such as TSql or MySql in the same method in C#

Currently I'm writing a program to access multiple 'types' of SQL servers, such as TSQL or MySQL in C#. I created a base class DBConnector that has an abstract method:
public abstract class DBConnector
{
//some other code...
protected abstract int ExecuteNonQueryOrScalar(DbConnection con, string statement, bool executeAsScalar, int timeout = 20);
//some other code...
}
Now I have two derived classes TSqlConnector and MySqlConnector which implement this abstract method:
For MySql it looks like this:
protected override int ExecuteNonQueryOrScalar(DbConnection con, string statement, bool executeAsScalar, int timeout = 20)
{
int result = -1;
using (MySqlCommand cmd = new MySqlCommand(statement, (MySqlConnection)con))
{
cmd.CommandTimeout = timeout;
cmd.Connection.Open();
if (executeAsScalar)
{
object resultObject = cmd.ExecuteScalar();
if (resultObject is int tmpResult)
result = tmpResult;
}
else
{
result = cmd.ExecuteNonQuery();
}
}
return result;
}
For TSql it looks like this:
protected override int ExecuteNonQueryOrScalar(DbConnection con, string statement, bool executeAsScalar, int timeout = 20)
{
int result = -1;
using (SqlCommand cmd = new SqlCommand(statement, (SqlConnection)con))
{
cmd.CommandTimeout = timeout;
cmd.Connection.Open();
if (executeAsScalar)
{
object resultObject = cmd.ExecuteScalar();
if (resultObject is int tmpResult)
result = tmpResult;
}
else
{
result = cmd.ExecuteNonQuery();
}
}
return result;
}
By the way, these methods also contain some error handling and some other stuff, but I simplified my methods for this post.
This method gets called in my other custom methods like that:
Code in my calling Insert-Method (obj is an instance of a model class which has the same properties as the database table, including ID):
obj.ID = ExecuteNonQueryOrScalar(GetConnection(), sql, true); //true for scalar-execution
Code in my calling Update-Method:
affectedLines = ExecuteNonQueryOrScalar(GetConnection(), sql, false); //false for nonQuery-execution
Code in my calling Delete-Method:
affectedLines = ExecuteNonQueryOrScalar(GetConnection(), sql, false); //false for nonQuery-execution
GetConnection() returns a DbConnection-Object which is either a SqlConnection or a MySqlConnection at runtime. sql is my sql-string. The boolean parameter decides whether to call ExecuteNonQuery or ExecuteScalar in ExecuteNonQueryOrScalar() as you can see in my code above.
Now to my questions:
As you can see, the code for the two implementations is almost the same. The only differences are the type of the connection and of the command. I have heard that you should follow the pattern "Don't repeat yourself". But I'm repeating myself here. Do you guys have an idea what I could do here? Or should I just stick what I currently have? I've had the idea to move the two methods to one single method in my base class DBConnector and work with generic parameters, which I limit with where T: IDBEntity and where K: DBConnection, but I get compile time errors when I do that. I couldn't really find a solution to prevent this.
Do you have any suggestions how to implement this differently? What would you change?
Let me know if I need to share more of my code.
Thank you for taking the time to read my question.
Edit: Solution to my question:
After I read the responses I realized how to improve my code. I moved my method ExecuteNonQueryOrScalar into the my base class DBConnector and added a IDbCommand-Parameter that can be any IDbCommand-Object at runtime. This method looks like this (simplified version):
protected int ExecuteNonQueryOrScalar(IDbCommand cmd, bool executeAsScalar, int timeout = 20)
{
int result = -1;
try
{
cmd.CommandTimeout = timeout;
if (cmd.Connection.State != ConnectionState.Open)
cmd.Connection.Open();
if (executeAsScalar)
{
string resultObject = cmd.ExecuteScalar().ToString();
if (Int32.TryParse(resultObject, out int tmpResult)) //if (resultObject is int tmpResult)
result = tmpResult;
}
else
{
result = cmd.ExecuteNonQuery();
}
}
//Some error handling...
finally
{
if (cmd.Connection.State != ConnectionState.Closed)
cmd.Connection.Close();
}
return result;
}
Here's an example how I call that ExecuteNonQueryOrScalar-Method in my Update-Method (simplified) in the same DBConnector-Class:
protected int Update<T, K>(T obj, List<DBCondition> filterValues = null) where T : IDBEntity, new() where K : IDbCommand, new()
{
int affectedLines = -1;
if (obj != null)
{
using (IDbCommand cmd = new K())
{
cmd.Connection = GetConnection();
cmd.CommandText = obj.GetSqlUpdateStatement(DBMapping.GetDBMapping<T>(), _sqlSpecificSymbols, filterValues);
affectedLines = ExecuteNonQueryOrScalar(cmd, false);
}
}
return affectedLines;
}
And finally here are two examples how I call this update-method in my MySqlConnector or TSqlConnector:
MySqlConnector:
public override int Update<T>(T obj, List<DBCondition> filterValues = null)
{
return base.Update<T, MySqlCommand>(obj, filterValues); //Call DbConnector.Update<T, K>() from the example above
}
TSqlConnector:
public override int Update<T>(T obj, List<DBCondition> filterValues = null)
{
return base.Update<T, SqlCommand>(obj, filterValues); //Call DbConnector.Update<T, K>() from the example above
}
Please don't hesitate to ask me if you want to see more of my code! I could also upload my not-simplified original code to sites such as github if some of you want to go through everything I did.

Your idea is a good one. But someone on the .net team has saved you some time by creating interfaces that work this way, like IDBConnection and IDBCommand.
Then there are different concrete implementations of this interface that you can use when needed. For example IDBConnection con = new MySqlConnection for MySQL, or IDBConnection con = new SqlConnection for SQL Server.
These interfaces expose common methods, like ExecuteNonQuery. So what you're working with in your code is just a bunch of interfaces. Your code always passes around IDBConnections and IDBCommands, you just choose whichever implementation you need at construction time. This is dependency inversion.
Of course, when populating the actual text of the command, you will have to use the right SQL dialect.
Does this do what you were trying to do?

Getting The SqlParameter is already contained by another SqlParameterCollection error with c# / ASP.net app

I have a generic method which is adding parameters to a cmd.parameters collection. I am getting the following error when 2 people are hitting the same stored procedure at the same time:
The SqlParameter is already contained by another SqlParameterCollection.
I have already searched within StackOverflow and also elsewhere on the web but so far I am not able to rectify the problem. My code is as follows:
protected DataSet ExecuteDataSet(string StoredProcName, List<TParameter> Params) {
bool internalOpen = false;
DataSet resultDataSet = null;
TDataAdapter dataAdapter;
TCommand cmd;
try {
resultDataSet = new DataSet();
dataAdapter = new TDataAdapter();
cmd = new TCommand();
cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = StoredProcName;
if (transaction != null) {
cmd.Transaction = transaction;
cmd.Connection = transaction.Connection;
} else {
cmd.Connection = connection;
}
if (Params != null && Params.Count > 0) {
foreach (TParameter param in Params) {
cmd.Parameters.Add(param);
}
}
dataAdapter.SelectCommand = cmd;
if (connection.State == ConnectionState.Closed) {
connection.Open();
internalOpen = true;
}
dataAdapter.Fill(resultDataSet);
dataAdapter.SelectCommand.Parameters.Clear();
cmd.Parameters.Clear();
return resultDataSet;
} catch {
throw;
} finally {
if (internalOpen) {
connection.Close();
}
}
The error is happening during the foreach loop but despite clearing parameters and applying some other attempted fixes I have been unable to prevent this error from happening.
This is being called from another method using the following:
result = base.ExecuteDataSet(procName,this.ConvertArrayList(this.ParamsList));
It is an older c# / asp.net (web forms) application that I am using, so the code reflects this.
The error message begins like so:
[ArgumentException: The SqlParameter is already contained by another SqlParameterCollection.]
System.Data.SqlClient.SqlParameterCollection.Validate(Int32 index, Object value) +5955779
System.Data.SqlClient.SqlParameterCollection.Add(Object value) +34
I am testing using 2 browsers logging in as 2 users at the same time and clicking a link to a page which pulls multiple records. One of these users gets the error while the other gets the correct page with returned results as expected.
Any help would be appreciated. Apologies if I haven't explained this well enough but I've been looking at this all day and haven't been able to progress.
Thanks in advance.
EDIT:
The ParamsList is set/get like this:
public ArrayList ParamsList {
get {
//Check to see if the parameters list has been initialised.
if (m_paramsList == null) {
//Create a new empty parameters list to pass back.
m_paramsList = new ArrayList();
}
return m_paramsList;
}
set {
m_paramsList = value;
}
}
And populated like so:
internal void AddParameter(string name, string value) {
IDbDataParameter param = CreateStringParameter(name);
param.Value = GetValueFromString(value);
Dal.ParamsList.Add(param);
}
for every type of parameter type....
internal void AddParameter(string name, double? value) {
internal void AddParameter(string name, byte[] value) {
etc...

Looking through the code in the question... a lot of it didn't accomplish what the author likely intended. The try/catch/finally, for example, was completely worthless because the catch block just re-threw the same exception and using the Fill() method meant the finally block was not needed. Other code has similar issues.
Except for the transactions, you could reduce the code down to just this, assuming TCommand and company fully implement the ADO.Net providers, where the reduced code actually increases performance, safety, and utility:
protected DataSet ExecuteDataSet(string StoredProcName, IEnumerable<TParameter> Params = null)
{
DataSet resultDataSet = new DataSet();
using (var cn = new TConnection(connection.ConnectionString))
using (var cmd = new TCommand(StoredProcName, cn))
using (var adapter = new TAdapter(cmd))
{
cmd.CommandType = CommandType.StoredProcedure;
if (Params != null)
{
foreach (TParameter param in Params)
{
cmd.Parameters.Add(param);
}
}
adapter.Fill(resultDataSet);
}
return resultDataSet;
}
But we do have that transaction value, and that's enough to break the using pattern here. Because of that, you'll want to effectively double the code length, to account for both variants. Yes, the using pattern really is that important, that you would effectively double the code length to keep it where possible:
protected DataSet ExecuteDataSet(string StoredProcName, IEnumerable<TParameter> Params = null)
{
DataSet resultDataSet = new DataSet();
if (transaction == null)
{
using (var cn = new TConnection(connection.ConnectionString))
using (var cmd = new TCommand(StoredProcName, cn))
using (var adapter = new TAdapter(cmd))
{
cmd.CommandType = CommandType.StoredProcedure;
if (Params != null)
{
foreach (TParameter param in Params)
{
cmd.Parameters.Add(param);
}
}
adapter.Fill(resultDataSet);
}
}
else
{
using (var cmd = new TCommand(StoredProcName, transaction.Connection))
using (var adapter = new TAdapter(cmd))
{
cmd.Transaction = transaction;
cmd.CommandType = CommandType.StoredProcedure;
if (Params != null)
{
foreach (TParameter param in Params)
{
cmd.Parameters.Add(param);
}
}
adapter.Fill(resultDataSet);
}
}
return resultDataSet;
}
Finally, none of this will fix your problem. The problem you're seeing is caused by code elsewhere trying too hard to re-use Parameter objects. You'll need to look at other code to fix the issue.

I am guessing that TCommand is a type of SqlCommand, and TParameter is a type of SqlParameter. I think the problem is here:
foreach (TParameter param in Params) {
cmd.Parameters.Add(param);
}
param is a member of Params, which is a reference type; this means that you will potentially be sharing the same list of Params between multiple calls to ExecuteDataSet. Instead, do something like this:
foreach (TParameter param in Params) {
cmd.Parameters.Add(new SqlParameter(param.ParameterName, param.SqlDbType, param.Size)).Value = param.Value;
}
Also, you could be potentially sharing the same SqlConnection between multiple threads, which could be a problem. Generally I would recommend creating a new SqlConnection within the ExecuteDataSet method. The new SqlConnection will still be able to enlist within any in-flight transaction.
Finally, use "using" blocks for all IDisposable objects, e.g., SqlCommand, SqlCommand, DataSet etc.

It sounds like the objects in this.ParamsList are being reused for every query. If you show how that list is defined and populated, we can confirm, but that's what it sounds like.
The solution is basically not to do that. Rebuild the parameter list with brand new SqlParameter objects for each query.
Otherwise you would have to employ some kind of locking to make sure two requests are not executed at the same time, but that seems like a worse solution.

How to unit test database methods in C#?

I've searched everywhere, but nothing I found was applicable to my current situation.
I have a class that helps with DB connections, and I need to unit test some of its methods:
public class DBHelper
{
private SqlConnection conn;
private SqlCommand textCommand;
public DBHelper(IDbConnection connection)
{
conn = (SqlConnection)connection;
textCommand = new SqlCommand();
textCommand.Connection = conn;
}
public SqlConnection Conn
{
get
{
return conn;
}
set
{
if (conn != null)
{
conn.Close();
conn.Dispose();
}
conn = (SqlConnection)value;
textCommand = new SqlCommand();
textCommand.Connection = conn;
textCommand.CommandType = CommandType.Text;
}
}
public object QueryScalar(string query)
{
textCommand.CommandText = query;
string qtype = query.Substring(0, 6).ToLower();
if (qtype == "select")
return textCommand.ExecuteScalar();
return textCommand.ExecuteNonQuery();
}
}
I know I shouldn't access the database from the test. I tried using mock objects but I don't think they can help here, because I cannot change textCommand from the outside of the class. I tried setting up an SQLite database and accessing it through SQL, but to no avail.
My question is: How can I unit test QueryScalar method?
Thank you for any ideas.

Perhaps you can use something like this in your class...
private IScalarQuerier _scalarQueryer;
public DBHelper(IDbConnection connection, IScalarQuerier q)
{
_scalarQuerier = q;
conn = (SqlConnection)connection;
textCommand = new SqlCommand();
textCommand.Connection = conn;
}
... and then place the QueryScalar method in a separate class, where you can do / test whatever you want. Just make that class implement an interface IScalarQuerier, so you can pass it in to DBHelper.
Might not be exactly what you were looking for, but this should let you do what you need with the method you want to test.
Sidenote: When you then pass that class (or IScalarQuerier-implementation, to be precise) into DBHelper, you should simply assume that the querier has been tested outside the scope of DBHelper, and that it therefore can be trusted to work correctly.

writing more optimized code and reusing code in C#

I'm writing a desktop application using C# winforms and MSSQL server 2012. there are several classes exit in this application that need to connect to database and all uisng ADO.Net. this is on of my classes :
class Prices
{
private int id = 0;
public int Id
{
get { return id; }
set { id = value; }
}
private string materialName = string.Empty;
......
......
......
public void updateMaterialPrice()
{
string conString = ConfigurationManager.ConnectionStrings["secaloFormulaCS"].ToString();
using (SqlConnection sqlCon = new SqlConnection(conString))
using (SqlCommand sqlCmd = new SqlCommand("spUpdateMaterialPrice", sqlCon))
{
sqlCmd.CommandType = CommandType.StoredProcedure;
sqlCmd.Parameters.AddWithValue("materialName",MaterialName);
sqlCmd.Parameters.AddWithValue("unitPrice", Price);
sqlCmd.Parameters.AddWithValue("carbohydrate", Carbohydrtate);
sqlCmd.Parameters.AddWithValue("protein", Proterin);
sqlCmd.Parameters.AddWithValue("fat", Fat);
sqlCmd.Parameters.AddWithValue("humidity", Humadity);
sqlCmd.Parameters.AddWithValue("minerlas", Minerlas);
sqlCon.Open();
sqlCmd.ExecuteNonQuery();
sqlCon.Close();
sqlCon.Dispose();
}
}
public void addMaterial()
{
string ConString = ConfigurationManager.ConnectionStrings["secaloFormulaCS"].ToString();
using(SqlConnection sqlCon = new SqlConnection(ConString))
using(SqlCommand sqlCmd = new SqlCommand("spAddMaterial",sqlCon))
{
sqlCmd.CommandType = CommandType.StoredProcedure;
sqlCmd.Parameters.AddWithValue("materialName", MaterialName);
sqlCmd.Parameters.AddWithValue("unitPrice",Price);
sqlCmd.Parameters.AddWithValue("carbohydrate",Carbohydrtate);
sqlCmd.Parameters.AddWithValue("proterin", Proterin);
sqlCmd.Parameters.AddWithValue("fat",Fat);
sqlCmd.Parameters.AddWithValue("humidity", Humadity);
sqlCmd.Parameters.AddWithValue("minerals",Minerlas);
sqlCon.Open();
sqlCmd.ExecuteNonQuery();
sqlCon.Close();
sqlCon.Dispose();
}
as you can see in addMterial() and updateMaterialPrice() i use the same code to connect to database and call a stored procedure and this is repeated for several times in my other classes. how can i prevent this code repetition ? is it any way to just write the code needed for connection and query the database one time and reuse it several times according to situation needed ?

I use a Factory pattern for my Database connections, this means I never have to open a SqlConnection or pass connection strings around my program.
Here is an example for the method I use to run a query that returns multiple rows.
I would call the method from a "makeObject" method that would turn this datatable into an object.
public static class DB
{
private static readonly string connectionString = ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
private static readonly DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.SqlClient");
/// <summary>
/// Use when returning data from multiple rows
/// </summary>
/// <param name="sql">query</param>
/// <param name="parameters">declared parameters</param>
/// <returns>datatable of db rows</returns>
public static DataTable GetDataTable(string sql, SqlParameter[] parameters)
{
try
{
using (DbConnection connection = factory.CreateConnection())
{
connection.ConnectionString = connectionString;
using (DbCommand command = factory.CreateCommand())
{
command.Connection = connection;
command.CommandType = CommandType.Text;
command.CommandText = sql;
if (parameters != null)
{
foreach (var parameter in parameters)
{
if (parameter != null)
command.Parameters.Add(parameter);
}
}
using (DbDataAdapter adapter = factory.CreateDataAdapter())
{
adapter.SelectCommand = command;
DataTable dt = new DataTable();
adapter.Fill(dt);
return dt;
}
}
}
}
catch (Exception)
{
throw;
}
}
}

Well, you could make a helper method to prepare the command for you, or at least fill the parameters, eg.
void PrepareParameters(SqlCommand cmd)
{
cmd.Parameters.AddWithValue("materialName",MaterialName);
cmd.Parameters.AddWithValue("unitPrice", Price);
cmd.Parameters.AddWithValue("carbohydrate", Carbohydrtate);
cmd.Parameters.AddWithValue("protein", Proterin);
cmd.Parameters.AddWithValue("fat", Fat);
cmd.Parameters.AddWithValue("humidity", Humadity);
cmd.Parameters.AddWithValue("minerlas", Minerlas);
}
Ideally, unless you want to use a ready ORM like Entity Framework (usually a good idea), you'd create a few abstract classes to handle these kinds of things, so that you'll save on code reuse.
For example, the PrepareParameters method could be abstract, and there could be an abstract property that returns the name of the SP to update, create or delete (or better yet, you could follow a naming scheme so that you'd only need one name). Then you could write 99% of the logic in the abstract base classes, and only prepare the parameters in the actual derived classes, thus cutting code repetition a lot.

Some options are as follows:
Write a SqlHelper class which does the repetitive grunt work of executing a stored procedure. (especially ExecuteNonQuery ones, so that you don't need to worry about return types.)
e.g.
public void ExecuteQuery(string sprocName, SqlParamater[] parameters)
{
// initialize connection
// construct command with sprocName and parameters
// ExecuteNonQuery
}
Use Linq2Sql
This is an excellent quick ORM tool which simplies data access to a great deal.
Use Entity Framework
This is an increasingly used ORM tool.
All of the above approaches have their pros/cons. You need to weight them & select the right method.

What's the most DRY-appropriate way to execute an SQL command?

I'm looking to figure out the best way to execute a database query using the least amount of boilerplate code. The method suggested in the SqlCommand documentation:
private static void ReadOrderData(string connectionString)
{
string queryString = "SELECT OrderID, CustomerID FROM dbo.Orders;";
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand command = new SqlCommand(queryString, connection);
connection.Open();
SqlDataReader reader = command.ExecuteReader();
try
{
while (reader.Read())
{
Console.WriteLine(String.Format("{0}, {1}", reader[0], reader[1]));
}
}
finally
{
reader.Close();
}
}
}
mostly consists of code that would have to be repeated in every method that interacts with the database.
I'm already in the habit of factoring out the establishment of a connection, which would yield code more like the following. (I'm also modifying it so that it returns data, in order to make the example a bit less trivial.)
private SQLConnection CreateConnection()
{
var connection = new SqlConnection(_connectionString);
connection.Open();
return connection;
}
private List<int> ReadOrderData()
{
using(var connection = CreateConnection())
using(var command = connection.CreateCommand())
{
command.CommandText = "SELECT OrderID FROM dbo.Orders;";
using(var reader = command.ExecuteReader())
{
var results = new List<int>();
while(reader.Read()) results.Add(reader.GetInt32(0));
return results;
}
}
}
That's an improvement, but there's still enough boilerplate to nag at me. Can this be reduced further? In particular, I'd like to do something about the first two lines of the procedure. I don't feel like the method should be in charge of creating the SqlCommand. It's a tiny piece of repetition as it is in the example, but it seems to grow if transactions are being managed manually or timeouts are being altered or anything like that.
edit: Assume, at least hypothetically, there's going to have to be a bunch of different types of data being returned. And consequently the solution can't be just one one-size-fits-all method, there will have to be a few different ones depending, at minimum, on whether ExecuteNonQuery, ExecuteScalar, ExecuteReader, ExecuteReaderAsync, or any of the others are being called. I'd like to cut down on the repetition among those.

Tried Dapper?
Granted this doesn't get you a DataReader but you might just prefer it this way once you've tried it.
It's about the lightest-weight an ORM can be while still being called an ORM. No more methods to map between DataReader and strong types for me.
Used right here on all the StackExchange sites.
using (var conn = new SqlConnection(cs))
{
var dogs = connection.Query("select name, age from dogs");
foreach (dynamic dog in dogs)
{
Console.WriteLine("{0} age {1}", dog.name, dog.age);
}
}
or
using (var conn = new SqlConnection(cs))
{
var dogs = connection.Query<Dog>("select Name, Age from dogs");
foreach (Dog dog in dogs)
{
Console.WriteLine("{0} age {1}", dog.Name, dog.Age);
}
}
class Dog
{
public string Name { get; set; }
public int Age { get; set; }
}

If you want to roll data access on your own, this pattern of help methods could be one way to remove duplication:
private List<int> ReadOrderData()
{
return ExecuteList<int>("SELECT OrderID FROM dbo.Orders;",
x => x.GetInt32("orderId")).ToList();
}
private IEnumerable<T> ExecuteList(string query,
Func<IDataRecord, T> entityCreator)
{
using(var connection = CreateConnection())
using(var command = connection.CreateCommand())
{
command.CommandText = query;
connection.Open();
using(var reader = command.ExecuteReader())
{
while(reader.Read())
yield return entityCreator(reader);
}
}
}
You'll have to add support for parameters and this might not compile, but the pattern is what I'm trying to illustrate.

What I typically do is use a custom class that I wrote a while back that accepts a SQL string, and optionally a list of parameters and it returns a DataTable.
Since the thing that changes between invocations is typically just the SQL that is optimal IMHO.
If you truly do need to use a DataReader you can do something like this:
public void ExecuteWithDataReader(string sql, Action<DataReader> stuffToDo) {
using (SqlConnection connection = new SqlConnection(connectionString)) {
using (SqlCommand command = new SqlCommand(sql, connection)) {
connection.Open();
using (SqlDataReader reader = command.ExecuteReader()) {
try {
while (reader.Read()) {
stuffToDo(reader);
}
}
finally {
reader.Close();
}
}
}
}
}
private static void ReadOrderData(string connectionString) {
string sql = "SELECT OrderID, CustomerID FROM dbo.Orders;";
ExecuteWithDataReader(sql, r => Console.WriteLine(String.Format("{0}, {1}", r[0], r[1])));
}

The first two line are the most important thing you need...
but if you still wish to do it, you can turn them to a database handler class, yes it will become more of code, but in refactoring concept, every thing will move to the related topic...
try to write a singleton class, that receive a command and do action, so return result of type SqlDataReader reader...

Doing this in comments was too much.
I would suggest that the boilerplate code around
using(conn = new sqlconnection)
using(cmd = new sqlcommand) {
// blah blah blah
}
isn't something to be lightly removed and instead would encourage that you keep it exactly where it's at. Resources, especially unmanaged ones, should be opened and released at the closest point to execution as possible IMHO.
In no small part due to the ease with which other developers will fail to follow the appropriate clean up conventions.
If you do something like
private SQLConnection CreateConnection()
{
var connection = new SqlConnection(_connectionString);
connection.Open();
return connection;
}
Then you are inviting another programmer to call this method and completely fail to release the resource as soon as the query is executed. I don't know what kind of app you are building, but in a web app such a thing will lead to memory / connection / resource errors of types that are difficult to debug, unless you've been through it before.
Instead, I'd suggest you look into a lightweight ORM such as Dapper.net or similar to see how they approached it. I don't use dapper, but I hear it's pretty good. The reason I don't use it is simply that we don't allow inline sql to be executed against our databases (but that's a very different conversation).
Here's our standard:
public static DataTable StatisticsGet( Guid tenantId ) {
DataTable result = new DataTable();
result.Locale = CultureInfo.CurrentCulture;
Database db = DatabaseFactory.CreateDatabase(DatabaseType.Clients.ToString());
using (DbCommand dbCommand = db.GetStoredProcCommand("reg.StatsGet")) {
db.AddInParameter(dbCommand, "TenantId", DbType.Guid, tenantId);
result.Load(db.ExecuteReader(dbCommand));
} // using dbCommand
return result;
} // method::StatisticsGet
We make heavy use of Enterprise Library. It's short, simple and to the point and very well tested. This method just returns a datatable but you could easily have it return an object collection.. or nothing.