«

The first application I wrote using asp.net started off rather small,
and as a result, the design of the application took a "Rapid
Application Development" type of approach. By this I mean that it was
simply built using a simple 3 tier architecture, where the interface
was created using css and master pages, the middle layer or business
logic classes, consisted of some simple public classes that defined
some of the business rules, and the underlying data layer contained
all the stored procedures and database schema. Everything worked fine,
since it was a rather simple application, and it was only being used
by a few people. Well, as some of you may already know, after each
demo, the new requirements kept getting added to the application, and
now it is turning into a huge application that is expected to be used
by hundreds of people. Incorporating a design pattern into the
application would have been a good idea, but I was not familiar with
some of the patterns when I started writing the application. I am also
not experienced with thread safety. Considering I am limited on
time(only a couple of weeks(2 or 3)), what are some things you experts
can suggest I take to prevent some unforeseen problems? FYI, All the
classes in my app_code folder are declared public. Nothing is static.

carlos wrote:
> The first application I wrote using asp.net started off rather small,
> and as a result, the design of the application took a "Rapid
> Application Development" type of approach. By this I mean that it was
> simply built using a simple 3 tier architecture, where the interface
> was created using css and master pages, the middle layer or business
> logic classes, consisted of some simple public classes that defined
> some of the business rules, and the underlying data layer contained
> all the stored procedures and database schema.

That sounds rather good. If it's really a three tier application, where
the presentation layer is completely isolated from the data layer, it's
pretty good.

If, on the other hand, the application only pretends to be layered, it's
not very good. This is usually visible by the fact that the presentation
layer is littered with database field names.

> Everything worked fine,
> since it was a rather simple application, and it was only being used
> by a few people. Well, as some of you may already know, after each
> demo, the new requirements kept getting added to the application, and
> now it is turning into a huge application that is expected to be used
> by hundreds of people. Incorporating a design pattern into the
> application would have been a good idea, but I was not familiar with
> some of the patterns when I started writing the application. I am also
> not experienced with thread safety. Considering I am limited on
> time(only a couple of weeks(2 or 3)), what are some things you experts
> can suggest I take to prevent some unforeseen problems? FYI, All the
> classes in my app_code folder are declared public. Nothing is static.

If you don't have any static variables, you are pretty safe when it
comes to thread safety. As long as each instance of an object only is
used in one thread, it's safe. Also, only one page at a time is executed
for each session, so any data that is session specific is also thread
safe in an ASP.NET application.

--
Göran Andersson
_____
http://www.guffa.com

I'll chime in here to say don't implement patterns for the sake of patterns
either. Patterns solve specific problems. Don't invent the problem just so
you can apply the pattern in code. I used to be guilty of that - it made my
code overly complicated. Cool for me, difficult for others to maintain.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET - MS Press
Professional VSTO 2005 - Wrox/Wiley
OWC Black Book www.lulu.com/owc

"Göran Andersson" <> wrote in message
news:%...
> carlos wrote:
>> The first application I wrote using asp.net started off rather small,
>> and as a result, the design of the application took a "Rapid
>> Application Development" type of approach. By this I mean that it was
>> simply built using a simple 3 tier architecture, where the interface
>> was created using css and master pages, the middle layer or business
>> logic classes, consisted of some simple public classes that defined
>> some of the business rules, and the underlying data layer contained
>> all the stored procedures and database schema.
>
> That sounds rather good. If it's really a three tier application, where
> the presentation layer is completely isolated from the data layer, it's
> pretty good.
>
> If, on the other hand, the application only pretends to be layered, it's
> not very good. This is usually visible by the fact that the presentation
> layer is littered with database field names.
>
>> Everything worked fine,
>> since it was a rather simple application, and it was only being used
>> by a few people. Well, as some of you may already know, after each
>> demo, the new requirements kept getting added to the application, and
>> now it is turning into a huge application that is expected to be used
>> by hundreds of people. Incorporating a design pattern into the
>> application would have been a good idea, but I was not familiar with
>> some of the patterns when I started writing the application. I am also
>> not experienced with thread safety. Considering I am limited on
>> time(only a couple of weeks(2 or 3)), what are some things you experts
>> can suggest I take to prevent some unforeseen problems? FYI, All the
>> classes in my app_code folder are declared public. Nothing is static.
>
> If you don't have any static variables, you are pretty safe when it comes
> to thread safety. As long as each instance of an object only is used in
> one thread, it's safe. Also, only one page at a time is executed for each
> session, so any data that is session specific is also thread safe in an
> ASP.NET application.
>
> --
> Göran Andersson
> _____
> http://www.guffa.com