some features needed

[John Viele]

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.

[Ben Reese]

Sounds to me like you want to create all of your DataAdapters and SQLConection objects at runtime instead of dropping them onto the designer

For preference I would not personally use the designer for any objects without a UI, or at least a large numer of properties that would remain static for the duration of the program.

[Chris Smith]

I think I have came across you of your issues, and may be able to help.

Problem 1.
Not sure if this really helps, but it sounds like your getting into some
intense apps. As good or bad VSS works with data objects, you will have to
draw the line and say. This need to be in a data access layer. So, using a
data access layer (DAL) will get rid of the data objects like data adapters
all together in your asp.net page. There are some very good free ones as
well, but I highly recommend llblgen pro if you can get it, or the free
version is just fine to.

Problem 2.
Maybe dynamic properties will help you. You can find these in the properties
window. They work with your app.conf or web.conf to populate settings. And
if you are deploying to a client site and all that have to do deploy the app
is edit the web.config or app.config, and run a db script. Then, you have
done most everything right.

Problem 3.
I somewhat agree with you, but this is just the tip of the whole stateless
iceberg. It gets even worse to create web controls on the fly. (make sure
you set those id's) it also seems that using a data access layer will keep
you from doing allot of that copying and pasting. You also may want to look
into learning more about OO design. Take a look at your Option 2 for this
problem. You could create a class, and create shared functions, and just put
imports mysharedfunctio ns at the top of your page. No more copying into
pages, you can just include them in where you need. But there even better
ways of doing this, such as a DAL, or what they used to call components
(assemblies). Separate your app into 3 sections, Presentation, DAL and
datasource. Allot of your problems will go away. As well as being able to
update and maintain your code easier.

I would agree that these and other issues as well seem like a mountain to
overcome from time to time, but I truly believe that MS did us all a favor
with .NET and ASP.NET, and VSS.NET was a godsend. The implementation of
these technologies I believe were made with good intention as well.
(Remember, nothing is perfect)

Oh, and if you need some examples of any of this, take a look at the
quickstart tuts from asp.net

Hope this helps.

Chris Smith
"John Viele" <jo************ **@hummingbird. com> wrote in message
news:e6******** ******@TK2MSFTN GP12.phx.gbl...

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.