Should Data Classes be Shared/Static Assemblies?

[Random]

Here's a design question I'm curious to know if anyone here has wrestled
with before...

I'm writing my data access methods in classes in the App_Code directory. I
know that I can easily instantiate each class on a page and run it's
functions to get my data from the database. However, I'm wondering if I
could pick up performance if I made all the functions shared/static. Then
I'm wondering if it would be worth it because of the design issues - namely
that I would have to pass in a parameter that would indicate which database
the function would have to access (each client group has it's own database).
If they're not shared/static I can pass in the parameter on the constructor.

I want to be able to still take advantage of connection pooling. Any ideas?

[Robbe Morris [C# MVP]]

This sentence in and of itself is bad design:

"data access methods in classes in the App_Code directory"

Your data layer ought to be an a separate assembly.
If you ever needed to put an database access stuff
in a windows service or perhaps a windows application,
you couldn't just copy the dll.

The methods being static won't affect connection pooling.

Personally, I like to have my data access methods static to
save lines of code instantiating objects. I also keep
static arrays of custom attributes and PropertyInfo stuff
because of the sql server object mapper mentioned below.

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"Random" <ci*******@hotm ail.comwrote in message
news:uO******** ********@TK2MSF TNGP04.phx.gbl. ..

Here's a design question I'm curious to know if anyone here has wrestled
with before...

I'm writing my data access methods in classes in the App_Code directory.
I know that I can easily instantiate each class on a page and run it's
functions to get my data from the database. However, I'm wondering if I
could pick up performance if I made all the functions shared/static. Then
I'm wondering if it would be worth it because of the design issues -
namely that I would have to pass in a parameter that would indicate which
database the function would have to access (each client group has it's own
database). If they're not shared/static I can pass in the parameter on the
constructor.

I want to be able to still take advantage of connection pooling. Any
ideas?

[Random]

I have to respectfully disagree with you, Robbe, that this is bad design.
Our programming group is mired right now in a very poorly performing
application because the application was abstracted so much that data access
and tasks were a nightmare for any new functionality or database schema
changes to the application; which happens to be often.

We expect to correct these problems by elimintating "awareness" of the
database schema in the application front end, and handling all the business
logic (outside of some validation) through custom classes and explicit
stored procedures. If we expect to need to share an assembly with a windows
service or windows application, we'll write one for that purpose and put it
in the GAC.

But, yes, I also had hoped to be able to write my data access methods as
shared/static to avoid the instantiation of objects when the page processes;
and if each business client didn't have their own database, that would be a
piece of cake. Now, if I can't make my functions shared/static because of
this, I'm wondering if/how I can make use of the HttpContext.Ite ms to keep
from needing to reference more than one per page process, or maybe have the
objects part of a thread pool I can pull them from.

"Robbe Morris [C# MVP]" <jo*****@joe.co mwrote in message
news:56******** *************** ***********@mic rosoft.com...

This sentence in and of itself is bad design:

"data access methods in classes in the App_Code directory"

Your data layer ought to be an a separate assembly.
If you ever needed to put an database access stuff
in a windows service or perhaps a windows application,
you couldn't just copy the dll.

The methods being static won't affect connection pooling.

Personally, I like to have my data access methods static to
save lines of code instantiating objects. I also keep
static arrays of custom attributes and PropertyInfo stuff
because of the sql server object mapper mentioned below.

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"Random" <ci*******@hotm ail.comwrote in message
news:uO******** ********@TK2MSF TNGP04.phx.gbl. ..

>Here's a design question I'm curious to know if anyone here has wrestled
with before...

I'm writing my data access methods in classes in the App_Code directory.
I know that I can easily instantiate each class on a page and run it's
functions to get my data from the database. However, I'm wondering if I
could pick up performance if I made all the functions shared/static.
Then I'm wondering if it would be worth it because of the design issues -
namely that I would have to pass in a parameter that would indicate which
database the function would have to access (each client group has it's
own database). If they're not shared/static I can pass in the parameter
on the constructor.

I want to be able to still take advantage of connection pooling. Any
ideas?