Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Should Data Classes be Shared/Static Assemblies?

Reply
Thread Tools

Should Data Classes be Shared/Static Assemblies?

 
 
Random
Guest
Posts: n/a
 
      12-19-2006
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?


 
Reply With Quote
 
 
 
 
Robbe Morris [C# MVP]
Guest
Posts: n/a
 
      12-20-2006
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" <(E-Mail Removed)> wrote in message
news:uO7%(E-Mail Removed)...
> 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?
>
>


 
Reply With Quote
 
 
 
 
Random
Guest
Posts: n/a
 
      12-20-2006
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.Items 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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:uO7%(E-Mail Removed)...
>> 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?
>>
>>

>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Instantiating classes / sharing data between classes Trevoke Ruby 10 07-22-2009 09:21 PM
Class Member Data and Member Function Parameters - Should Parameters Be Data Members? Jason C++ 2 05-13-2006 07:11 AM
What the FAQs should and should not contain Josef 'Jupp' SCHUGT Ruby 0 08-19-2005 01:46 PM
taking 70-290 should i be scared? What should i expect??? Raymond Munyan MCSE 31 12-01-2004 02:34 PM
How should control images should be handled? ~~~ .NET Ed ~~~ ASP .Net Building Controls 1 11-03-2004 12:30 PM



Advertisments