Should Data Classes be Shared/Static Assemblies?

Discussion in 'ASP .Net' started by Random, Dec 19, 2006.

  1. Random

    Random Guest

    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, Dec 19, 2006
    #1
    1. Advertising

  2. 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/adonet_source_code_generator.asp





    "Random" <> wrote in message
    news:uO7%...
    > 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], Dec 20, 2006
    #2
    1. Advertising

  3. Random

    Random Guest

    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]" <> wrote in message
    news:...
    > 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/adonet_source_code_generator.asp
    >
    >
    >
    >
    >
    > "Random" <> wrote in message
    > news:uO7%...
    >> 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, Dec 20, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. RadekP
    Replies:
    0
    Views:
    883
    RadekP
    Jun 25, 2003
  2. Invalidlastname

    ASP.NET and shared assemblies

    Invalidlastname, Dec 1, 2003, in forum: ASP .Net
    Replies:
    8
    Views:
    842
    Jim Cheshire [MSFT]
    Dec 4, 2003
  3. Phi!
    Replies:
    1
    Views:
    311
    Philip Q [MVP]
    Apr 23, 2004
  4. Sam-I-Am
    Replies:
    3
    Views:
    7,403
    Steven Cheng[MSFT]
    Jul 21, 2004
  5. Javier Martinez
    Replies:
    27
    Views:
    754
    Juan T. Llibre
    Nov 15, 2005
Loading...

Share This Page