Again, with the SqlConnection in Session variable

[Hal Meyer]

Okay... I've got a fairly straightforward web store, which keeps the obvious
in Session variables:

Customer object
Order object

I also, however, have a large class (which is also used by the WinForms app
that manages products/customers) which I keep in a Session variable. It
contains a SqlConnection, and am curious as to just how bad a practice this
would be considered. Pseudo-code below:

-- global.asax --

void Session_Start(object sender, EventArgs e)
{
Session["DataManager"] = new DataManager([...connection string
....]);
}


-- datamanager.cs --

//Field declaration
private SqlConnection _conn;

//Constructor
public DataManager(string connectionString)
{
_conn = new SqlConnection(connectionString);
}

//Get an object
public TypeA GetTypeA(int objectID)
{
_conn.Open();
[... TypeA object created from a SqlDataReader ...]
_conn.Close();

return objectA;
}

//Save an object
public void SaveTypeA(TypeA objectA)
{
_conn.Open();
[... Insert/Update SqlCommands executed inside a transaction...]
_conn.Close();
}


-- default.aspx --

DataManager dataMgr;
TypeA objectA;

void Page_Load(object sender, EventArgs e)
{
dataMgr = (DataManager)Session["DataManager"];

if(!Page.IsPostBack)
objectA = dataMgr.GetTypeA(objectID);
}

 

[Göran Andersson]

Okay... I've got a fairly straightforward web store, which keeps the obvious
in Session variables:

Customer object
Order object

I also, however, have a large class (which is also used by the WinForms app
that manages products/customers) which I keep in a Session variable. It
contains a SqlConnection, and am curious as to just how bad a practice this
would be considered. Pseudo-code below:

-- global.asax --

void Session_Start(object sender, EventArgs e)
{
Session["DataManager"] = new DataManager([...connection string
...]);
}


-- datamanager.cs --

//Field declaration
private SqlConnection _conn;

//Constructor
public DataManager(string connectionString)
{
_conn = new SqlConnection(connectionString);
}

//Get an object
public TypeA GetTypeA(int objectID)
{
_conn.Open();
[... TypeA object created from a SqlDataReader ...]
_conn.Close();

return objectA;
}

//Save an object
public void SaveTypeA(TypeA objectA)
{
_conn.Open();
[... Insert/Update SqlCommands executed inside a transaction...]
_conn.Close();
}


-- default.aspx --

DataManager dataMgr;
TypeA objectA;

void Page_Load(object sender, EventArgs e)
{
dataMgr = (DataManager)Session["DataManager"];

if(!Page.IsPostBack)
objectA = dataMgr.GetTypeA(objectID);
}

At least you don't try to keep the connection alive between requests.
That would have been bad...

I don't see any reason to put the DataManager object in a session
variable. It doesn't contain any information that you need to keep from
one request to the other.

Just create a new DataManager object when you need one. Creating the
SqlConnection object itself isn't expensive, almost all the work is done
in the methods of the class.

 

[sloan]

Man dude, I don't know exactly how to word it, but what you're doing makes
little sense.

You should keep the ConnectionStringName in a session variable (maybe,
probably?). That is of course if you hit different databases. If you hit
only one database, then the default database is good.
(The EnterpriseLibrary.Data allows you to pick one connection string as the
default).

If you're using 2.0 or above, you can name your connection strings.

You can also try to create a real DAL layer (and BAL layer). The word
"SqlConnection" (IMHO) should not even appear in the presentation layer.

You need to investigate Connection Pooling. When you close a connection, it
gets returned to the pool. When you need another connection, it (can) come
from the pool. That's the .02 cent version.

I would move to a Controller/Manager style class.

As in, a CustomerController and a OrderController.
Don't mix the entity object code with the code that creates them. Don't
assume your entities (Customer,Order) will always come from a database,
especially a SqlServer database.

........

Take a look here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

There is a DAL (which uses the EnterpriseLibrary.Data as its ~helper), a BAL
and a basic presentation layer.

There is a 1.1 version of that same blog entry at my blog site. Read it as
well. You also want to follow the "bird's eye view" article I mention at
the bottom of my 1.1 "Custom Objects and Collections" article.

....
My accessment of the code you posted is that is "cutesy" for the sake of
being cutesy.
:<

Okay... I've got a fairly straightforward web store, which keeps the
obvious in Session variables:

Customer object
Order object

I also, however, have a large class (which is also used by the WinForms
app that manages products/customers) which I keep in a Session variable.
It contains a SqlConnection, and am curious as to just how bad a practice
this would be considered. Pseudo-code below:

-- global.asax --

void Session_Start(object sender, EventArgs e)
{
Session["DataManager"] = new DataManager([...connection string
...]);
}


-- datamanager.cs --

//Field declaration
private SqlConnection _conn;

//Constructor
public DataManager(string connectionString)
{
_conn = new SqlConnection(connectionString);
}

//Get an object
public TypeA GetTypeA(int objectID)
{
_conn.Open();
[... TypeA object created from a SqlDataReader ...]
_conn.Close();

return objectA;
}

//Save an object
public void SaveTypeA(TypeA objectA)
{
_conn.Open();
[... Insert/Update SqlCommands executed inside a transaction...]
_conn.Close();
}


-- default.aspx --

DataManager dataMgr;
TypeA objectA;

void Page_Load(object sender, EventArgs e)
{
dataMgr = (DataManager)Session["DataManager"];

if(!Page.IsPostBack)
objectA = dataMgr.GetTypeA(objectID);
}