Attn: Application Architects... Design Question... please give me your feedback...

  • Thread starter Thread starter alien2_51
  • Start date Start date
A

alien2_51

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....
 
Alien,

There is no problem with your design approach.

FYI - The "single save botton" issue is just a symptom of
a bigger problem -- watch your back.
 
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.
 
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
 
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
 
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
 
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 said:
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
Click to expand...
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.
 
Steve C. Orr said:
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
Click to expand...

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
 
Back
Top