Every time I create ASP.NET pages that do any significant data access, I
find myself having to deal with the same problems: managing data object
creation, the SQL connection object especially.
Problem 1: If I have a pile of data adapters on a page, I typically only
need a single SQL connection object, though the designer always tries to add
a new one for each data adapter. So I have to manually weed out the extras
and set the data adapters to use the same connection object. I should be
able to default VS.NET to that behavior instead of doing extra work every
time.
Problem 2: The connection string is static in the designer. It ought to
provide a dynamic means.
I'm constantly having to struggle with the designer vs. what happens at
runtime. For example, when I am creating pages that are going to be
deployed at some client's site, they are going to want some means to
configure the connect string. Obviously I can stick it in the registry or
some CFG file and give them a simple UI means of changing it. However, the
designer generates code that executes when the page loads. If I modify that
code, then the designer gets confused. If, on the other hand, I change the
SQL object dynamically at run time, I can really only do that AFTER it has
already tried to create one for me...one with the wrong connect string.
It's a chicken/egg thing.
One possible solution would be to allow me to specify a function that
returns the connect string instead of the string itself. There are a couple
of other ways one could approach this, but I'll cut it off there.
Problem 3: Object creation....all data objects are created from the ground
up every time the page loads. When I have pages which use more than a
couple of data adapters, that starts to add up, and often I don't really
need most of those objects on every page load, I may only need a few. So,
for optimization, I tend to copy/paste code generated in the designer into
separate functions so that I have the flexibility of creating those objects
when they are actually needed. Of course, I have to leave the old objects
in there and just comment them out at release time or else I lose the nice
features that the designer gives me. Option 2 is I create all of them on a
separate page, then copy/paste the code to the page I actually need them on.
That way I can continue to use the designer, but then I have to
re-copy/paste everything when I make modifications.
It might be nice to give this one some in-depth consideration and come up
with a more elegant solution than just "fire up all the data objects every
time the page loads". Maybe the VS.NET team could add a simple feature such
as a way to demarcate a chunk of code as belonging to the designer so that
all the generated code would not neccessarily HAVE to be lodged in a known
function. Then I could move out the chunks to where I need them without
totally blowing away the designer. I'd have no problem with it generating
the code in the usual place by default, of course.
find myself having to deal with the same problems: managing data object
creation, the SQL connection object especially.
Problem 1: If I have a pile of data adapters on a page, I typically only
need a single SQL connection object, though the designer always tries to add
a new one for each data adapter. So I have to manually weed out the extras
and set the data adapters to use the same connection object. I should be
able to default VS.NET to that behavior instead of doing extra work every
time.
Problem 2: The connection string is static in the designer. It ought to
provide a dynamic means.
I'm constantly having to struggle with the designer vs. what happens at
runtime. For example, when I am creating pages that are going to be
deployed at some client's site, they are going to want some means to
configure the connect string. Obviously I can stick it in the registry or
some CFG file and give them a simple UI means of changing it. However, the
designer generates code that executes when the page loads. If I modify that
code, then the designer gets confused. If, on the other hand, I change the
SQL object dynamically at run time, I can really only do that AFTER it has
already tried to create one for me...one with the wrong connect string.
It's a chicken/egg thing.
One possible solution would be to allow me to specify a function that
returns the connect string instead of the string itself. There are a couple
of other ways one could approach this, but I'll cut it off there.
Problem 3: Object creation....all data objects are created from the ground
up every time the page loads. When I have pages which use more than a
couple of data adapters, that starts to add up, and often I don't really
need most of those objects on every page load, I may only need a few. So,
for optimization, I tend to copy/paste code generated in the designer into
separate functions so that I have the flexibility of creating those objects
when they are actually needed. Of course, I have to leave the old objects
in there and just comment them out at release time or else I lose the nice
features that the designer gives me. Option 2 is I create all of them on a
separate page, then copy/paste the code to the page I actually need them on.
That way I can continue to use the designer, but then I have to
re-copy/paste everything when I make modifications.
It might be nice to give this one some in-depth consideration and come up
with a more elegant solution than just "fire up all the data objects every
time the page loads". Maybe the VS.NET team could add a simple feature such
as a way to demarcate a chunk of code as belonging to the designer so that
all the generated code would not neccessarily HAVE to be lodged in a known
function. Then I could move out the chunks to where I need them without
totally blowing away the designer. I'd have no problem with it generating
the code in the usual place by default, of course.
Comment