When using auto-generated TableAdapters, what is the suggested way to deal with repeated instantiation?

Question

I am using the .xsd dataset thingies (which I hate) to auto-generate TableAdapter classes for some backend code. I have not really used these before, tending to favour manual commands and stored procs whenever possible (for various speed-induced reasons: those xsds play hell with dynamic tables and really large amounts of columns), and am finding myself instantiating a TableAdapter in a large number of my methods, so my question is this:

Will the auto-generated code automatically streamline itself so that a full adapter class is not created on an instatiation, and instead share some static data (such as connection information), and if not would it be better for me to have some sort of singleton/static class provider that can give me access to their methods when needed without the overhead of creating a new adapter every time I want to get some information?

Cheers, Ed

Answer 1

I actually tend to instanciate a very low number of adapters (usually only one of each type). I never tried using them as on the stack variables (instantiated when needed), so I never ran into your question, but I understand your concern.

From what I know the aqdapters themselves may be quite heavyweight in instancing, but the real killer is the connection. What I do is I mark the adapter's Connection modifier as Public in the .xsd designer so I can assign the property whatever I need it to use, and maintain a tight grip on the opening and closing of connections:

void Load() {
  using (SqlConnection conn = ...) {
    conn.Open();
    invoicesAdapter.Connection = conn;
    customersAdapter.Connection = conn;
    invoicesAdapter.Fill(dataSet.Invoices);
    customersAdapter.Fill(dataSet.Customers);
  }
}

void Save() {
  using (SqlConnection conn = ...) {
    conn.Open();
    invoicesAdapter.Connection = conn;
    customersAdapter.Connection = conn;
    invoicesAdapter.Update(dataSet);
    customersAdapater.Update(dataSet);
  }
}

I ommitted transaction control and error handling for brevity.

Answer 2

If you're concerned about the performance you could always run a benchmark to see what the performance hit, if any, is.

Sorry you didn't find my answer useful.

My point was that while you had received responses they all seemed to be subjective and not based on hard data. So if you had some reason to be concerned that there was a performance hit in your particular application you should measure it.

There is no reason to refactor one area for performance unless there is an actual problem.