I am developing a MySQL Web App using ASP.net and I have heard that a using directive should be used for the mysql connection to ensure that the connection is always closed should something go wrong as their is no guarantee that the database will close from inside finally statement if a catch has occured (depending on the exception).
I am trying to create a class that opens the MySQL Connection so I haven't got to repeat the same code each time I need to access the database.
I have seen that it is something like
using (call class to open connection)
{
MySQL Stuff Here
}
I have seen that the class that is being called to open the connection needs to be an IDISOSABLe class but I am not sure how I can implement this.
However, I cannot find any information on how this can be done. Thanks for your help.
The typical way to implement the IDisposable interface is by following the pattern laid out in the example in the documentation: http://msdn.microsoft.com/en-us/library/system.idisposable.aspx
Basically, your class should/would look like this:
public sealed class YourClass : IDisposable
{
private MySqlConnection _Connection;
private bool _IsDisposed;
public YourClass()
{
_Connection = new MySqlConnection();
}
public void Dispose()
{
if (!_IsDisposed)
{
_Connection.Dispose(); // or Close
_IsDisposed = false;
}
}
}
There are numerous variants of this pattern, depending on whether you intend for others to inherit from your class, and whether you have any unmanaged resources you need to close (like file handles), but for normal use, the above is enough.
MSDN :)
http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx#Y800
However I'm not really sure what you are trying to achieve will be of any benefit to you. What is your wrapper class doing differently than just using the connection object
what data access design pattern are you using?
Related
I have a very interesting scenario where I would like a class to inform another entity it has been destroyed; however, its not doing what I want it too.
The Problem
The deconstructor, for some reason does not do what its supposed to do.
The Question
Why is the destructor not being invoked and make sure that it does do its necessary clean up.
The Code
So here we have the informer ~
class Connection
{
public const int Port = 50000;// Can be any range between 49152 and 65536
//Teh Constructor
public Boolean Connect()
{
//SetInformation
Information.Id = 545;
using (var WebServ = new ClientSDKSoapClient("ClientSDKSoap"))
{
ContinueConnection.WaitOne();
WebServ.ClientLogin(Information);
}
return true;
}
~Connection()
{
using (var WebServ = new ClientSDKSoapClient("ClientSDKSoap"))
{
WebServ.ClientLogout(Information);
}
}
}
Additional Information
I want the web service to record if the Connection Class is destroyed for any given reason.
When the client is connecting, it works perfectly. The Web Service records every method called from it. If I call ClientLogout explicitly, it will work.
I am aware I can implement IDisposable; however, this object is not intended to be used within the lifetime of one method. In fact, its intended for use for the entire duration of the program and the failure of this object basically results in the failure of the entire project. (Although I suppose main IS a method...)
I need to release a network connection; however, its not in this program, its in another program and unless ClientLogout is called, it won't be released.
My Research
Microsoft says that you should use the deconstructor for the release of unmanaged resources making an explicit reference to network connections. This ones got my quite stumped.
I think you should implement a Dispose pattern for your Connection class, rather than relying on an obscure deconstructor metaphor. This would be the "canonical" way to do it.
public class Connection : IDisposable // <== Inherit from IDisposable interface
{
public const int Port = 50000;// Can be any range between 49152 and 65536
private SomeType webserv; // Use whatever real type is appropriate here.
private Information information = new Information(); // or whatever
// This is a real constructor.
public Connection()
{
//SetInformation
information.Id = 545;
webServ = new ClientSDKSoapClient("ClientSDKSoap"))
webserv.ContinueConnection.WaitOne();
webServ.ClientLogin(information);
}
// Implement IDisposable interface
public void Dispose()
{
webServ.ClientLogout(information);
}
}
And then use it thusly
using (var connection = new Connection())
{
// Use the connection here.
}
The client will be logged out when you leave the using block.
Microsoft says that you should use the deconstructor for the release of unmanaged resources making an explicit reference to network connections. This ones got my quite stumped.
The docs here are misleading. It really just means you need a finalizer somewhere in your object inheritance chain, to ensure that any unmanaged resources are appropriately cleaned up. But you only need this finalizer once for the entire inheritance tree, at the level where the unmanaged resource is first allocated.
As an example, you do not need a destructor or finalizer if you build a class for a data access layer to wrap the SqlConnection type, because the core SqlConnection type already has one. What you should do, though, is implement IDisposable and write code to ensure prompt disposal, so the finalizer on your SqlConnection will be called sooner, rather than later. But if you were to build a whole new database engine that competes with Sql Server, MySql, Oracle, Access, and the like, and were implementing the ADO.Net provider for this new database engine, then would need to write a finalizer for your connection type, because none exists yet.
In this case, ClientSDKSoap type already has a destructor; you do not need to write another.
i am writing a windows form based application that uses database and
i want to declare the following as global so that i can just use vcon.open()
and vcon.close() to open and close my database from which ever form i want. please tell how to do it.
OleDbConnection vcon = new OleDbConnection(#"Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=F:\workspace\RDASMS\RDASMS\rdadb.mdb");
Connections are quite lightweight, so you can just create and close them as needed. Maybe like this:
using (var conn = new OleDbConnection(connStr))
{
// Use your connection
}
This will automatically close the connection for you when the block exits.
You might like to put the string in a globally accessible place, such as a Config class.
As the others have stated, "global" static types are not usually the best design approach, but to answer your specific question:
namespace YourApplicationNamespace
{
public static class MyOleDbConnection
{
public static OleDbConnection OleDbConnection;
public static void Open()
{
// Do Something with OleDbConnection.
}
public static void Close()
{
// Do Something with OleDbConnection.
}
}
}
Can be used as:
MyOleDbConnection.Open();
MyOleDbConnection.Close();
First of all you can't declare something global in a namespace. And even if it was possible it is not a nice idea. Appreciating your effort in avoiding code duplication, I suggest you to:
Place the connection string in the configuration.
Declare the connection and use it when needed, maybe with an using pattern.
a point about 2: I noticed you use a jet engine ( Access ) this can result in a performance drawback by opening and closing the connection on demand, or at least was as this in the past. In any case note than opening the connection when needed and close it as soon you have done is the pattern to follow in any other case.
You can create a static class with static members.
public static MyConnection
{
public static OleDbConnection Connection = new OleDbConnection(#"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=F:\workspace\RDASMS\RDASMS\rdadb.mdb");
}
Then you can access it like:
var vcon = MyConnection.Connection;
vcon.Open();
Doing it this way adds a unnecessary layer of complexity to your program. You should either create a class that strictly handles database access such as the MyConnection example above. You would need to add the appropriate methods to actually handle the access. Using the Jet provider can introduce significant performance implications when opening and closing a file constantly. You should only close it if there will be long periods of inactivity on the connection. In that case you should do something more along the lines of:
using(var vcon = new OleDbConnection(#"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=F:\workspace\RDASMS\RDASMS\rdadb.mdb"))
{
// Your code here...
}
This will close the connection once your operations are complete. But don't forget about the performance issues that can arise from this.
cn = new SqlConnection(
ConfigurationManager.ConnectionStrings["LocalSqlServer"].ToString());
cn.Open();
Where should this code go assuming I have content pages and master pages?
Should I put it in the master pages Page_Init? Will it then be fully accessible from every stage of execution on my content pages?
I'm used to classic ASP, so I would usually do it:
Declare variables
Open connection
process code
Close connection
Render HTML
But there are lots of stages of the page lifecycle in .net so I am wondering where it is best to place this code?
And does this connection need closing, or will garbage handling take care of it for me?
For me id create a DataAccess Layer so that I can remove the database connectivity in the codebehind files. My webapp will then reference the Dal and expose a public method that will allow Dal interaction from the front end
in terms of opening and closing Dal connections - wrap it in a using statement - that takes care of opening and closing the connection when required.
more information on this can be found here - http://davidhayden.com/blog/dave/archive/2005/01/13/773.aspx
I would go too for the Data Access Layer, but in order to answer your question more directly, here is how would I do this in ASP.NET, also handling transactions.
Override OnPreInit: initialize connection, open it and start new transaction
Override OnUnload: commit/rollback transaction, close connection
Override Dispose: dispose of both connection and transaction
I would also add a VoteRollback() method used to request a transaction rollback if something goes wrong. Page execution continues (you'll have to handle problems through your code) but when the page is unloaded the transaction is rolled back
I would recommend you create a seperate class library project that exposes classes that relate to your tables in your database. Then put a reference to that project and away you go. To simplify opening/closing connections, writing classes etc take a look at Subsonic which will map all your tables for you and then you can do something like this in your codebehind.
Product prod = Product.Find(3);
prod.Name = "iPhone";
prod.Save();
In .Net it depends on the structure you use. If you connect explicitly by manually using a SqlConnection object, you'll need to manage its connection directly. If you use a dataset tableadapter object or a DataContext object with LINQ (my personal recommendation), the connection is typically managed for you, but you'll want to enclose your object within a using block to make sure it is collected properly.
Our team's consideration of a "best practice" is to built a universal data manager that implements IDisposable in our common data class that handles the lazy-loading of any connection based objects to retrieve data. This way we can enforce the closing of any connections within the dispose events of that data manager to keep it clean.
Edit:
I always start with Guthrie.
http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
101 LINQ Samples
http://krisvandermotten.wordpress.com/2006/11/30/creating-a-data-access-layer-with-linq-to-sql-part-2/
Below is a code sample of a piece of my standard BaseDataManager. I should probably have created an interface for it a long time ago, but the abstract bit seems to get my other team members to adopt it fairly well. I post this code as is with no warranty, but it works for me, and it keeps my connection pool nice and clean (and we do a LOT of data pulls for document information stored in a database). I cut out a bunch of our other base methods to keep it simple, and what's below is the portion that answers your question directly:
[Serializable()]
public abstract class BaseDataManager : IDisposable
{
private bool _disposedValue = false;
private SqlConnection _connectionObject = null;
public BaseDataManager()
{
}
public BaseDataManager(string connectionString)
{
this.SqlConnectionString = connectionString;
}
public BaseDataManager(string connectionString, string username, string password)
{
if (!connectionString.EndsWith(";")) connectionString += ";";
this.SqlConnectionString += "User ID=" + username + ";password=" + password;
}
public string SqlConnectionString
{
get;
set;
}
public virtual SqlConnection Connection
{
get
{
if (_connectionObject == null && !String.IsNullOrEmpty(this.SqlConnectionString))
_connectionObject = new SqlConnection(this.SqlConnectionString);
return _connectionObject;
}
set
{
_connectionObject = value;
}
}
#region IDisposable Support
/// <summary>
/// (Protected) Method that performs actual cleanup on dispose. This interface
/// has been implemented to clean up data connections that are left stranded
/// when the class is disposed while the connection possibly remains open in
/// the connection pool. This opportunity is also used to free up the private
/// variables of the class.
/// </summary>
/// <param name="disposing">Used for explicitly calling Dispose</param>
protected virtual void Dispose(bool disposing)
{
if (!_disposedValue)
{
if (disposing)
{
//---------------------------------------------------------------------------------------------
// Close the connection object prior to setting it to nothing
//---------------------------------------------------------------------------------------------
if (_connectionObject != null) _connectionObject.Close();
_connectionObject = null;
}
_disposedValue = true;
}
}
/// <summary>
/// (Public) Method that implements IDisposable. This code is autogenerated
/// the implementation interface in the VS IDE. Do not change this code.
/// </summary>
public void Dispose()
{
// Do not change this code. Put cleanup code in Dispose(ByVal disposing As Boolean) above.
Dispose(true);
GC.SuppressFinalize(this);
}
#endregion
}
You should only be using it when you need data from your database.
If you are not creating a DAL layer, then you would put this is your events such as page_load, or onClick events. You should not be opening a connection just for the sake of opening a connection on the page.
snippet of code for opening up connection
SqlConnection conn = null
try
{
conn = new SqlConnection(ConfigurationManager.ConnectionStrings["LocalSqlServer"].ConnectionString);
conn.Open()
// do something with the connection
}
catch(Exception ex)
{
//log error
}
finally
{
// clean up connection
if(conn!=null)
{
//check if connetion is open, if it is close it / dispose
}
}
First thumb of rule, decouple the Domain layer from the ASP.NET specifics/View.
A lot of people create a class library for the Domain layer, that way it is guaranteed that the Page/View related code does not get blended with it.
So you would have a domain layer, where you have classes such as User, Comment, etc... and those classes would talk to the database. I usually have a DbUser class where all the database interaction happens, and DbUser inherits DbQuery which creates the connection for you. That way I can keep database interaction code completely to the Db{ClassName} class and DbQuery. It can really help if you want to keep the code really organized.
Simple scenario:
When I get a page request to view a profile of a specific user, I simply do User.GetUser(id); where id is the user id of the user. The User class has a static method GetUser, which creates a new instance of DbUser and calls the getUser method there. getUser method within the DbUser creates a connection and a query to the database, then it returns an instance of User and voila, you get it in your hands.
I hope my answer helps you in the right direction though it may be a bit off topic.
UPDATE: By decoupling the Domain layer from the website then you have more options, such as re-using the class library for another project that interacts to the same database.
This is a little wierd, but I want to check if connection to my database is already open or not? How do I check that? and if open I want to be able to work with it straightaway without going through all the statements:
sqlconnection conn = new sqlconnection("string ...");
Can this be done? I know the connection string and the connection name too. I want to check if this connection is available first and then proceed.
If you know the connection string then the easiest way of obtaining a new usable sql connection is to create a new instance of the SqlConnection class:
using (SqlConnection conn = new SqlConnection("MyConnectionString"))
{
conn.Open();
// Use the connection
}
The .Net framework uses connection pooling and so there is no need to worry about opening efficiency & multiple connections - the above code will either re-use an available existing connection, or create a new one as required.
If you want to save yourself some typing then you might find it useful to create yourself a small helper method or property:
class SqlHelper
{
public static SqlConnection GetConn()
{
SqlConnection returnValue = new SqlConnection("MyConnectionString");
returnValue.Open();
return returnValue;
}
}
Usage:
using (SqlConnection conn = SqlHelper.GetConn())
{
// Use the connection
}
Have you looked at the documentation for SqlConnection?
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
I believe the "State" property will tell you what you want.
If you are rather asking more generally how you can use an existing connection from a connection pool, this will be done automatically when you create a new SqlConnection with an identical connection string as an active connection.
If you're just trying to avoid writing redundant code, then put it in a class and reuse it.
Although you are probably just using SQL Server it might be good practice to get familiar with all the core interfaces in System.Data since all data providers implement them. I believe the State property on IDbConnection returns the information you are asking for (IDbConnection)
Also you may want to hide that logic in some kind of centralized method:
public static IDbConnection RetrieveConnection(){
if(DataAccess.Connection.State == ConnectionState.Open) return DataAccess.Connection;
conn.Dispose(); //to be clean, I believe this is safe if it's already disposed
//retrieve configured connection string
//create and open connection
return DataAccess.Connection;
}
So maybe DataAccess is some place you can put and retrieve your connection object, but I would avoid having everyone use it directly. Instead have them go through this method that can ensure the connection is usable. I'm just trying to give you ideas.
Also you may want to take it a step further and use something like NHibernate that will manage connections and all that stuff for you. Although that's not always worth the effort if the project is small.
EDIT: made the code a little more explicit
The Façade Design Pattern should help you here. Here's an example.
Façade Pattern (wikipedia);
Façade Design Pattern (Gang of Four).
An "intelligent" façade knows what method needs to connect where, etc. The façade opens the connection and pass it to an underlying piece of code, generally contained in a factory class or something alike.
public class DoSomethingFacade {
private static readonly DoSomethingFactory _doSomethingFactory = new DoSomethingFactory();
public static IList<T> GetList<T>() {
using(IDbConnection connection = OpenConnection("string..."))
return _doSomethingFactory.GetList<T>(connection);
}
public static IDbConnection OpenConnection(string connectionString) {
IDbConnection openedConnection = new SqlConnection(connectionString);
openedConnection.Open();
return openedConnection;
}
}
internal class DoSomethingFactory {
internal DoSomethingFactory() { }
internal IList<T> GetList<T>(IDbConnection connection) {
IList<T> results = new List<T>();
// use connection here without caring about it,
// as it should be provided as an opened available connection.
return results;
}
}
Was wondering if it is recomended to pass a database connection object around(to other modules) or let the method (in the other module) take care of setting it up. I am leaning toward letting the method set it up as to not have to check the state of the connection before using it, and just having the caller pass any needed data to the calling method that would be needed to setup the connection.
Personally I like to use tightly scoped connections; open them late, use them, and close them (in a "using" block, all within the local method). Connection pooling will deal with re-using the connection in most cases, so there is no real overhead in this approach.
The main advantage in passing connections used to be so that you could pass the transaction around; however, TransactionScope is a simpler way of sharing a transaction between methods.
Since the classes are implementation specific, I'd write each to open it's own native transaction. Otherwise, you can use the ado.net factory methods to create the appropriate type from the config file (the provider name).
Personally, I like storing a stack of my current open connection and transactions on top of the Thread Local Storage using SetData and GetData. I define a class that manages my connections to the database and allow it to use the dispose pattern. This saves me the need to pass connections and transactions around, which is something that I think clutters and complicates the code.
I would strongly recommend against leaving it up to the methods to open connections every time they need data. It will leads to a really bad situation where it is both hard to manage transactions throughout the application and too many connections are opened and closed (I know about connection pooling, it is still more expensive to look up a connection from the pool than it is to reuse an object)
So I end up having something along these lines (totally untested):
class DatabaseContext : IDisposable {
List<DatabaseContext> currentContexts;
SqlConnection connection;
bool first = false;
DatabaseContext (List<DatabaseContext> contexts)
{
currentContexts = contexts;
if (contexts.Count == 0)
{
connection = new SqlConnection(); // fill in info
connection.Open();
first = true;
}
else
{
connection = contexts.First().connection;
}
contexts.Add(this);
}
static List<DatabaseContext> DatabaseContexts {
get
{
var contexts = CallContext.GetData("contexts") as List<DatabaseContext>;
if (contexts == null)
{
contexts = new List<DatabaseContext>();
CallContext.SetData("contexts", contexts);
}
return contexts;
}
}
public static DatabaseContext GetOpenConnection()
{
return new DatabaseContext(DatabaseContexts);
}
public SqlCommand CreateCommand(string sql)
{
var cmd = new SqlCommand(sql);
cmd.Connection = connection;
return cmd;
}
public void Dispose()
{
if (first)
{
connection.Close();
}
currentContexts.Remove(this);
}
}
void Test()
{
// connection is opened here
using (var ctx = DatabaseContext.GetOpenConnection())
{
using (var cmd = ctx.CreateCommand("select 1"))
{
cmd.ExecuteNonQuery();
}
Test2();
}
// closed after dispose
}
void Test2()
{
// reuse existing connection
using (var ctx = DatabaseContext.GetOpenConnection())
{
using (var cmd = ctx.CreateCommand("select 2"))
{
cmd.ExecuteNonQuery();
}
}
// leaves connection open
}
For automated testing purposes, it's usually easier to pass it in. This is called dependency injection.
When you need to write tests, you can create a mock database connection object and pass that instead of the real one. That way, your automated tests won't rely on an actual database that needs to be repopulated with data every time.
I personally work to centralize my data access as much as possible, however, if not possible I ALWAYS open a new connection in the other classes, as I find that there are too many other things that can get in the way when passing the actual connection object.
Here is a little more insight into this problem. I have a class that manages db connections, and have 2 classes that implement an interface. One of the classes is for SQL and the other is of OLAP. The manager is the one that knows which connection to use, so it could pass the exact connection to the type, or the type can create his own connection.
You can pass connection objects without any problem (for instance Microsoft Enterprise Library allows static method calls passing in a connection) or you could manage it externally its up to your design, there are not direct technical tradeoffs.
Be careful for portability not to pass an specific connection if your solution will be ported to other databases (meaning don´t pass a SqlConnection it you plan to work with other databases)
Setting up the connection is potentially expensive and potentially adds a round trip. So, again, potentially, the better design is to pass the connection object.
I say potentially, because if you are a Microsoft ADO app, you are probably using a connection pool....
I would suggest that you distinguish between the connection object and its state (open, closed).
You can have a single method (or property) that reads the connection string from web.config. Using the same version of the connection string every time ensures that you will benefit from connection pooling.
Call that method when you need to open a connection. At the very last moment, after setting up all of the SqlCommand properties, open the connection, use it, and then close it. In C#, you can use the using statement to make sure the connection is closed. If not, be sure to close the connection in a finally block.
I would use the web.config
<configuration>
<connectionStrings>
<add name="conn1" providerName="System.Data.SqlClient" connectionString="string here" />
<add name="conn2" providerName="System.Data.SqlClient" connectionString="string here" />
</connectionStrings>
</configuration>
Then you can reference it from anywhere in the application