A Simple Managed Application in ASP

A Simple Managed Application
Here is a typical simple architecture for a smaller application with a single data store that’s n
expecting hundreds of concurrent users (see Figure 1-2). All of the components are managed
types. The ASP.NET pages use standard controls built into the Framework that generate
W3C-compliant HTML. This allows the application to be deployed to any platform or
operating system that supports a web browser. The pages use what could be a stateful busi-
ness object layer, but the application is simple enough that only a few of these stateful types
are actually needed. The business object layer, in turn, leverages a data access layer written
using the Data Access Application Block and calling SQL Server stored procedures.

In some cases, the UI layer calls the data access layer directly. Although this is a violation
of the guidance provided by the layering pattern, in this case, it’s acceptable as the business
rules aren’t that complex and, in many cases, would be nothing more than a “pass-thru” layer,
providing nothing but an additional level to the call stack and bloating your code base, assembly sizes, and heap allocations unnecessarily.

Even with this simple design, this application could scale out to handle additional load in
the future. The requirements for what needs to be managed in state are minimal enough that
they’re easily implemented using cookies (good only for small amounts of data), and the data-
base (more coding, but it’s persistent, scalable, and available).
Access to the database is synchronous, so any long-running queries would incur a delay
in the responsiveness of the application for the user, as there’s nothing in this design to
address asynchronous operations. The recovery plan, should the server go down, is to drive to
the office as fast as possible and repair or replace the machine. This results in a low availability
guarantee, which is acceptable because the application isn’t mission critical. Any requests
in-process during a system crash would be lost.
Deployment of new versions and fixes for this application are worry free. State informa-
tion is tracked in the database, and correlated to users with a cookie value. Both of these stores
survive the reboot of a web server.
This architecture would obviously not work for all applications. There are a number of
serious limitations. However, when the requirements are met by this solution, it’s an excellent
choice, because developing applications like these are extremely fast and very easy to learn,
compared to a lot of n-tiered applications.