I was tasked with designing an ASP.NET web application and one of the
requirements was a single save button.. The application consisted of approx
5 data input screens that affected approximately the same number of data
tables in the database, one of the tables required an attachment file that
was uploaded from the client via multi part form.. My question to you is
this: Given the same requirement (single save) on the same platform what
would be the solution you would have recommended..?? FYI... I've already
architected, designed, coded and deployed this application it's running in a
production environment with several hundred users as we speak.. Why would I
ask such a question then? Basically my design approach is in question by
some folks who have no business let alone the technical savvy to do so and I
would like you, the professionals, to give me some feedback that will
indicate to me one of two things..

1) I'm a dumb ass and have no business designing cutting edge web
applications, I should be delivering pizza to real application architects..
2) I've learned enough in the 12 yrs. of programming experience I have to
make good design decisions and should continue to do so..

A little more info about the app: The collection of data input screens make
up what I'll call a call sheet or customer call... All of the data collected
until the user presses the save button is considered the call sheet data.

Here's a brief description of my design approach...
I maintain call sheet data state in a DataSet that can be serialized to the
disk, database or the session. Session in my case. When the session times
out the dataset is persisted to the database so that the user, provide they
don't close their browser can reconnect with their previous session and
continue working seamlessly... Which works wonderfully... The problem these
folks are having is in my decision to use the DataSet, so I guess that where
I'd like your opinion mostly... Although, I'll appreciate your opinion in
whatever context you'd like to give it.. What other mechanism would have
been better suited for this task...??? I personally can think of nothing
that would better suit this requirement..

Thanks for your input....

Using a DataSet does not sound unreasonable to me. Has your associate said
why he thinks it was a bad decision for this particular app? (He likely
knows more about the project than any of the rest of us in the newsgroups.)
If the app works within the specified requirements then everyone should be
satisified.
Of course there are a number of other approaches you could have used, but I
can think of none that are obviously better than the one you chose
(overall).
A *slightly* better approach *might* have been to use a strongly typed
dataset or a custom object model instead, to more closely match your data
structure. Then save that into session (or wherever.) But that feels
almost like nitpicking. Like I said, if it ain't broke, no need to fix it.

--
I hope this helps,
Steve C. Orr, MCSD
http://Steve.Orr.net


"alien2_51" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I was tasked with designing an ASP.NET web application and one of the
> requirements was a single save button.. The application consisted of
approx
> 5 data input screens that affected approximately the same number of data
> tables in the database, one of the tables required an attachment file that
> was uploaded from the client via multi part form.. My question to you is
> this: Given the same requirement (single save) on the same platform what
> would be the solution you would have recommended..?? FYI... I've already
> architected, designed, coded and deployed this application it's running in
a
> production environment with several hundred users as we speak.. Why would
I
> ask such a question then? Basically my design approach is in question by
> some folks who have no business let alone the technical savvy to do so and
I
> would like you, the professionals, to give me some feedback that will
> indicate to me one of two things..
>
> 1) I'm a dumb ass and have no business designing cutting edge web
> applications, I should be delivering pizza to real application
architects..
> 2) I've learned enough in the 12 yrs. of programming experience I have to
> make good design decisions and should continue to do so..
>
> A little more info about the app: The collection of data input screens
make
> up what I'll call a call sheet or customer call... All of the data
collected
> until the user presses the save button is considered the call sheet data.
>
> Here's a brief description of my design approach...
> I maintain call sheet data state in a DataSet that can be serialized to
the
> disk, database or the session. Session in my case. When the session times
> out the dataset is persisted to the database so that the user, provide
they
> don't close their browser can reconnect with their previous session and
> continue working seamlessly... Which works wonderfully... The problem
these
> folks are having is in my decision to use the DataSet, so I guess that
where
> I'd like your opinion mostly... Although, I'll appreciate your opinion in
> whatever context you'd like to give it.. What other mechanism would have
> been better suited for this task...??? I personally can think of nothing
> that would better suit this requirement..
>
> Thanks for your input....
>
>

Approach sounds fine to me.

Can come up with some considerations (which I can't judge on validity
because you did not provide the requirements for them)

Saving inside the session is performance wise good, but will result in more
'lost work' when something goes wrong. If that would be a real issue
(filling in the sheet is timeconsuming or the data cannot be re-entered)
then I would take the performance cost of always going to the database.
(Appearantly you opted the other way around)

Actually thinking about it some more... Depending on how the app is actually
used by the end users It might give you better performace to always go to
the database. If in 90% or so of the time users finish their sheets from
page 1-5 without going back to previous pages and then hit save this _could_
be a faster solution that also will reduce the amount of memory used by the
webserver (and help scalability). Would require some testing to see if this
is actually true of false.

Scale out is a minor consideration (moving the app to a farm) in combination
with memory based session storage.

Again these points may be irrelavant in your actual case, but was trying to
come up with the reason your architecture is questioned. I really can't see
why a dataset as such would be an important issue. A nice object structure
might look codewise better but is then harder to sent to the database.

If you find out their arguments let us know. I'm curious.

Edwin Kusters
Hot ITem Informatica

"alien2_51" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I was tasked with designing an ASP.NET web application and one of the
> requirements was a single save button.. The application consisted of
approx
> 5 data input screens that affected approximately the same number of data
> tables in the database, one of the tables required an attachment file that
> was uploaded from the client via multi part form.. My question to you is
> this: Given the same requirement (single save) on the same platform what
> would be the solution you would have recommended..?? FYI... I've already
> architected, designed, coded and deployed this application it's running in
a
> production environment with several hundred users as we speak.. Why would
I
> ask such a question then? Basically my design approach is in question by
> some folks who have no business let alone the technical savvy to do so and
I
> would like you, the professionals, to give me some feedback that will
> indicate to me one of two things..
>
> 1) I'm a dumb ass and have no business designing cutting edge web
> applications, I should be delivering pizza to real application
architects..
> 2) I've learned enough in the 12 yrs. of programming experience I have to
> make good design decisions and should continue to do so..
>
> A little more info about the app: The collection of data input screens
make
> up what I'll call a call sheet or customer call... All of the data
collected
> until the user presses the save button is considered the call sheet data.
>
> Here's a brief description of my design approach...
> I maintain call sheet data state in a DataSet that can be serialized to
the
> disk, database or the session. Session in my case. When the session times
> out the dataset is persisted to the database so that the user, provide
they
> don't close their browser can reconnect with their previous session and
> continue working seamlessly... Which works wonderfully... The problem
these
> folks are having is in my decision to use the DataSet, so I guess that
where
> I'd like your opinion mostly... Although, I'll appreciate your opinion in
> whatever context you'd like to give it.. What other mechanism would have
> been better suited for this task...??? I personally can think of nothing
> that would better suit this requirement..
>
> Thanks for your input....
>
>

hi ..
this definetly comes from someone with a little less exp... but
actually I'm also doing a similar thing as in .. something like ur
brainbench .. user has to answer say 30-40 questions .. and i'm
displaying 5 questions .. and either .. planning to store it in the DB
after every click of "Next" or .. put the responses in an xml file
(with the session Id).. and then finally depending on ifthe user has
answered all the questions .. store it in the DB.
I'm looking into the typed dataset concept ....We would be having a
lot of users hitting our app at a time ..
any suggestions.. comments on this ...?

alien2_51
Perhaps you should send the "disenters" an application to work for the Pizza Delivery company!!

While I am not as 'experienced' as you, from the design standpoint, it looks solid to me. In fact, your design concept actually may be something I'll use for a project I'm working on, though I'm not going to be subject to the dunderheads whining, as most of my projects are purely "R&D" for my company.

One of my reference books addresses the design concept you used. Pragmatic ADO.NET by Shawn Wildermuth
From Chapter 11, Section 6, he describes "Best Practices." The headings are as follows (for what its worth):

-Use DataSet Schema
-Use Typed DataSets to Create Business Rule Layers
-Reduce Roundtrips to the Database
-Cache Data Early and Often
-Get and Use a DBA
-Isolate Developers from the Database
-Use DataReader Sparingly in ASP.NET
-Use Connection Factories
-Do Not Hard Code Connection Strings
-Keep Your Users Out of Your Database

The first four items are what I noticed, in reference to your design.

HTH

RMH

"alien2_51" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> I was tasked with designing an ASP.NET web application and one of the
> requirements was a single save button.. The application consisted of approx
> 5 data input screens that affected approximately the same number of data
> tables in the database, one of the tables required an attachment file that
> was uploaded from the client via multi part form.. My question to you is
> this: Given the same requirement (single save) on the same platform what
> would be the solution you would have recommended..?? FYI... I've already
> architected, designed, coded and deployed this application it's running in a
> production environment with several hundred users as we speak.. Why would I
> ask such a question then? Basically my design approach is in question by
> some folks who have no business let alone the technical savvy to do so and I
> would like you, the professionals, to give me some feedback that will
> indicate to me one of two things..
>
> 1) I'm a dumb ass and have no business designing cutting edge web
> applications, I should be delivering pizza to real application architects..
> 2) I've learned enough in the 12 yrs. of programming experience I have to
> make good design decisions and should continue to do so..
>
> A little more info about the app: The collection of data input screens make
> up what I'll call a call sheet or customer call... All of the data collected
> until the user presses the save button is considered the call sheet data.
>
> Here's a brief description of my design approach...
> I maintain call sheet data state in a DataSet that can be serialized to the
> disk, database or the session. Session in my case. When the session times
> out the dataset is persisted to the database so that the user, provide they
> don't close their browser can reconnect with their previous session and
> continue working seamlessly... Which works wonderfully... The problem these
> folks are having is in my decision to use the DataSet, so I guess that where
> I'd like your opinion mostly... Although, I'll appreciate your opinion in
> whatever context you'd like to give it.. What other mechanism would have
> been better suited for this task...??? I personally can think of nothing
> that would better suit this requirement..
>
> Thanks for your input....
>
>

I don't have an issue with using the dataset. However, I wonder if
you are working in a web farm environment and if so, how are you
guarenteed that the user will be reconnected to the same machine?

Jonathan Schafer


On Tue, 15 Jul 2003 12:31:41 -0400, "RMH" <(E-Mail Removed)> wrote:

>alien2_51
> Perhaps you should send the "disenters" an application to work for the Pizza Delivery company!!
>
> While I am not as 'experienced' as you, from the design standpoint, it looks solid to me. In fact, your design concept actually may be something I'll use for a project I'm working on, though I'm not going to be subject to the dunderheads whining, as most of my projects are purely "R&D" for my company.
>
> One of my reference books addresses the design concept you used. Pragmatic ADO.NET by Shawn Wildermuth
>From Chapter 11, Section 6, he describes "Best Practices." The headings are as follows (for what its worth):
>
>-Use DataSet Schema
>-Use Typed DataSets to Create Business Rule Layers
>-Reduce Roundtrips to the Database
>-Cache Data Early and Often
>-Get and Use a DBA
>-Isolate Developers from the Database
>-Use DataReader Sparingly in ASP.NET
>-Use Connection Factories
>-Do Not Hard Code Connection Strings
>-Keep Your Users Out of Your Database
>
>The first four items are what I noticed, in reference to your design.
>
>HTH
>
>RMH
>
>"alien2_51" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
>> I was tasked with designing an ASP.NET web application and one of the
>> requirements was a single save button.. The application consisted of approx
>> 5 data input screens that affected approximately the same number of data
>> tables in the database, one of the tables required an attachment file that
>> was uploaded from the client via multi part form.. My question to you is
>> this: Given the same requirement (single save) on the same platform what
>> would be the solution you would have recommended..?? FYI... I've already
>> architected, designed, coded and deployed this application it's running in a
>> production environment with several hundred users as we speak.. Why would I
>> ask such a question then? Basically my design approach is in question by
>> some folks who have no business let alone the technical savvy to do so and I
>> would like you, the professionals, to give me some feedback that will
>> indicate to me one of two things..
>>
>> 1) I'm a dumb ass and have no business designing cutting edge web
>> applications, I should be delivering pizza to real application architects..
>> 2) I've learned enough in the 12 yrs. of programming experience I have to
>> make good design decisions and should continue to do so..
>>
>> A little more info about the app: The collection of data input screens make
>> up what I'll call a call sheet or customer call... All of the data collected
>> until the user presses the save button is considered the call sheet data.
>>
>> Here's a brief description of my design approach...
>> I maintain call sheet data state in a DataSet that can be serialized to the
>> disk, database or the session. Session in my case. When the session times
>> out the dataset is persisted to the database so that the user, provide they
>> don't close their browser can reconnect with their previous session and
>> continue working seamlessly... Which works wonderfully... The problem these
>> folks are having is in my decision to use the DataSet, so I guess that where
>> I'd like your opinion mostly... Although, I'll appreciate your opinion in
>> whatever context you'd like to give it.. What other mechanism would have
>> been better suited for this task...??? I personally can think of nothing
>> that would better suit this requirement..
>>
>> Thanks for your input....
>>
>>

Jonathan,
In 'my' environment, we do have a number of Web Servers, however, not in a "Web Farm" configuration.

In this type of situation, I would say that a different approach would have to be taken. As such,
I'll defer the answer to someone who 'does' utilize Web Farms.

RMH

"Jonathan Schafer" <jschafer@*NOSPAM*brierley.a.b.c.com> wrote in message
news:(E-Mail Removed)...
> I don't have an issue with using the dataset. However, I wonder if
> you are working in a web farm environment and if so, how are you
> guarenteed that the user will be reconnected to the same machine?
>
> Jonathan Schafer
>
>
> On Tue, 15 Jul 2003 12:31:41 -0400, "RMH" <(E-Mail Removed)> wrote:
>
> >alien2_51
> > Perhaps you should send the "disenters" an application to work for the Pizza Delivery company!!
> >
> > While I am not as 'experienced' as you, from the design standpoint, it looks solid to me. In
fact, your design concept actually may be something I'll use for a project I'm working on, though I'm not
going to be subject to the dunderheads whining, as most of my projects are purely "R&D" for my company.
> >
> > One of my reference books addresses the design concept you used. Pragmatic ADO.NET by Shawn
Wildermuth
> >From Chapter 11, Section 6, he describes "Best Practices." The headings are as follows (for what its
worth):
> >
> >-Use DataSet Schema
> >-Use Typed DataSets to Create Business Rule Layers
> >-Reduce Roundtrips to the Database
> >-Cache Data Early and Often
> >-Get and Use a DBA
> >-Isolate Developers from the Database
> >-Use DataReader Sparingly in ASP.NET
> >-Use Connection Factories
> >-Do Not Hard Code Connection Strings
> >-Keep Your Users Out of Your Database
> >
> >The first four items are what I noticed, in reference to your design.
> >
> >HTH
> >
> >RMH
> >
> >"alien2_51" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> >> I was tasked with designing an ASP.NET web application and one of the
> >> requirements was a single save button.. The application consisted of approx
> >> 5 data input screens that affected approximately the same number of data
> >> tables in the database, one of the tables required an attachment file that
> >> was uploaded from the client via multi part form.. My question to you is
> >> this: Given the same requirement (single save) on the same platform what
> >> would be the solution you would have recommended..?? FYI... I've already
> >> architected, designed, coded and deployed this application it's running in a
> >> production environment with several hundred users as we speak.. Why would I
> >> ask such a question then? Basically my design approach is in question by
> >> some folks who have no business let alone the technical savvy to do so and I
> >> would like you, the professionals, to give me some feedback that will
> >> indicate to me one of two things..
> >>
> >> 1) I'm a dumb ass and have no business designing cutting edge web
> >> applications, I should be delivering pizza to real application architects..
> >> 2) I've learned enough in the 12 yrs. of programming experience I have to
> >> make good design decisions and should continue to do so..
> >>
> >> A little more info about the app: The collection of data input screens make
> >> up what I'll call a call sheet or customer call... All of the data collected
> >> until the user presses the save button is considered the call sheet data.
> >>
> >> Here's a brief description of my design approach...
> >> I maintain call sheet data state in a DataSet that can be serialized to the
> >> disk, database or the session. Session in my case. When the session times
> >> out the dataset is persisted to the database so that the user, provide they
> >> don't close their browser can reconnect with their previous session and
> >> continue working seamlessly... Which works wonderfully... The problem these
> >> folks are having is in my decision to use the DataSet, so I guess that where
> >> I'd like your opinion mostly... Although, I'll appreciate your opinion in
> >> whatever context you'd like to give it.. What other mechanism would have
> >> been better suited for this task...??? I personally can think of nothing
> >> that would better suit this requirement..
> >>
> >> Thanks for your input....
> >>
> >>
>

"Steve C. Orr, MCSD" <(E-Mail Removed)> wrote in message news:#(E-Mail Removed)...
> Using a DataSet does not sound unreasonable to me. Has your associate said
> why he thinks it was a bad decision for this particular app? (He likely
> knows more about the project than any of the rest of us in the newsgroups.)
> If the app works within the specified requirements then everyone should be
> satisified.
> Of course there are a number of other approaches you could have used, but I
> can think of none that are obviously better than the one you chose
> (overall).
> A *slightly* better approach *might* have been to use a strongly typed
> dataset

I entertained using typed datasets early on in the process, one of the things that I didn't like was that if the
underlying schema changed, the dataset must be regenerated in order to benefit from the new schema.
The approach I took seems to allow the data provider to determine the content my dataset contains.
I can't help but think to myself that somehow I'm reinventing the wheel here, with a "mini database" and all,
possibly this is why some of my counter parts are confused about the benefits of using the dataset.

A couple nice benefits I noticed.
a.. Personal transaction cache with built in data constraints enforcement. thinking there's a pattern for reuse here;-)
b.. Reduction in network traffic and SQL load by reading system tables only once.
c.. Extremely XML:able, easy serialization to many storage mechanisms, easy to scale.
d.. HasChanges at every level in the dataset object hiearchy is simply wonderful (no more change tracking code).

or a custom object model instead, to more closely match your data
> structure. Then save that into session (or wherever.) But that feels
> almost like nitpicking. Like I said, if it ain't broke, no need to fix it.
>
> --
> I hope this helps,
> Steve C. Orr, MCSD
> http://Steve.Orr.net
>
>
> "alien2_51" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > I was tasked with designing an ASP.NET web application and one of the
> > requirements was a single save button.. The application consisted of
> approx
> > 5 data input screens that affected approximately the same number of data
> > tables in the database, one of the tables required an attachment file that
> > was uploaded from the client via multi part form.. My question to you is
> > this: Given the same requirement (single save) on the same platform what
> > would be the solution you would have recommended..?? FYI... I've already
> > architected, designed, coded and deployed this application it's running in
> a
> > production environment with several hundred users as we speak.. Why would
> I
> > ask such a question then? Basically my design approach is in question by
> > some folks who have no business let alone the technical savvy to do so and
> I
> > would like you, the professionals, to give me some feedback that will
> > indicate to me one of two things..
> >
> > 1) I'm a dumb ass and have no business designing cutting edge web
> > applications, I should be delivering pizza to real application
> architects..
> > 2) I've learned enough in the 12 yrs. of programming experience I have to
> > make good design decisions and should continue to do so..
> >
> > A little more info about the app: The collection of data input screens
> make
> > up what I'll call a call sheet or customer call... All of the data
> collected
> > until the user presses the save button is considered the call sheet data.
> >
> > Here's a brief description of my design approach...
> > I maintain call sheet data state in a DataSet that can be serialized to
> the
> > disk, database or the session. Session in my case. When the session times
> > out the dataset is persisted to the database so that the user, provide
> they
> > don't close their browser can reconnect with their previous session and
> > continue working seamlessly... Which works wonderfully... The problem
> these
> > folks are having is in my decision to use the DataSet, so I guess that
> where
> > I'd like your opinion mostly... Although, I'll appreciate your opinion in
> > whatever context you'd like to give it.. What other mechanism would have
> > been better suited for this task...??? I personally can think of nothing
> > that would better suit this requirement..
> >
> > Thanks for your input....
> >
> >
>
>

Thanks... I appreciate all your feedback...



"alien2_51" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I was tasked with designing an ASP.NET web application and one of the
> requirements was a single save button.. The application consisted of
approx
> 5 data input screens that affected approximately the same number of data
> tables in the database, one of the tables required an attachment file that
> was uploaded from the client via multi part form.. My question to you is
> this: Given the same requirement (single save) on the same platform what
> would be the solution you would have recommended..?? FYI... I've already
> architected, designed, coded and deployed this application it's running in
a
> production environment with several hundred users as we speak.. Why would
I
> ask such a question then? Basically my design approach is in question by
> some folks who have no business let alone the technical savvy to do so and
I
> would like you, the professionals, to give me some feedback that will
> indicate to me one of two things..
>
> 1) I'm a dumb ass and have no business designing cutting edge web
> applications, I should be delivering pizza to real application
architects..
> 2) I've learned enough in the 12 yrs. of programming experience I have to
> make good design decisions and should continue to do so..
>
> A little more info about the app: The collection of data input screens
make
> up what I'll call a call sheet or customer call... All of the data
collected
> until the user presses the save button is considered the call sheet data.
>
> Here's a brief description of my design approach...
> I maintain call sheet data state in a DataSet that can be serialized to
the
> disk, database or the session. Session in my case. When the session times
> out the dataset is persisted to the database so that the user, provide
they
> don't close their browser can reconnect with their previous session and
> continue working seamlessly... Which works wonderfully... The problem
these
> folks are having is in my decision to use the DataSet, so I guess that
where
> I'd like your opinion mostly... Although, I'll appreciate your opinion in
> whatever context you'd like to give it.. What other mechanism would have
> been better suited for this task...??? I personally can think of nothing
> that would better suit this requirement..
>
> Thanks for your input....
>
>