ASP 101 - Active Server Pages 101 - Web01
The Place ASP Developers Go!

Please visit our partners

Windows Technology Windows Technology
15 Seconds
ASP 101
ASP Wire
VB Forums
VB Wire
internet.commerce internet.commerce
Partners & Affiliates

ASP 101 is an site
ASP 101 is an site
Internet News
Small Business
Personal Technology

Corporate Info
Tech Jobs
E-mail Offers

ASP 101 News Flash ASP 101 News Flash

 Top ASP 101 Stories Top ASP 101 Stories
Getting Scripts to Run on a Schedule
The Top 10 ASP Links @
What is and Why Do I Need It?

IIS Reset
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates

Building an ASP.NET App: John's DVD Catalog - Part 2: Planning

by John Peterson


Probably the most overlooked step in ASP development is the planning stage. You wouldn't take a vacation without planning first and you probably wouldn't even go see a movie without seeing when and where it was playing, but many developers spend almost no time at all planning their web projects before they start writing the code. With a small one or two page project you can often get away with that, but you'll find the practice coming back to haunt you when you go to tackle a larger project and quickly find yourself in over your head.

The usual justification is that the project is simple or that sitting down and documenting the requirements takes too much time. Time is obviously important and you certainly don't want to waste it, but starting a project without a firm grasp on it's scope and complexity often leads to unexpected problems and unnecessary delays. These often consume as much (if not more) time and effort then the planning stage would have taken in the first place.

Here comes the "do as I say and not as I do" disclaimer.  ;)   Since my project is somewhat less then mission critical and I know in advance that this is going to continue to be a work in progress and I'm the only one who will be writing the code, I'm doing just about the minimum amount of planning... much less then I probably should be.

Goals of the DVD Catalog Project

It's always good to try and come up with a comprehensive list of goals when starting a project. One of the best ways to do this is often to ask for user or operator input. This is where you guys came into play by sending in all your requests for features. The other thing you should always do is ask your boss... they often have interesting requirements that no one else would ever come up with!  ;)   I should probably compile a neat list, but since requests are still rolling in and we are trying to hit a moving target, for now just give the feedback page a read to get an idea of what will be included and what won't. Just be sure to come back here when you're done!


Now that we've got some ideas what the completed project is supposed to be able to do, we're going to start sketching some basic diagrams of the different parts of the project. It might seem pretty silly, but they're really easy and can help you get a clear mental picture of the project. I'm going to quickly outline the user interface and some of the database tables we'll be creating and finish with a quick pass of the three different tiers we'll be using to build our app.

Keep in mind that these steps are simply meant to give you a better idea of what you're facing and help you get a clear understanding of the application you are trying to build. These are meant to be somewhat simplistic for the sake of illustration, but when doing this in real life, the time and effort involved should be proportional to the size and complexity of the project. It's almost impossible to do too much planning and you should continue until you and your team all have a clear idea of just what it is you're setting out to build. Don't worry is the going is slow. There's nothing wrong with spending a few days or even weeks planning something if that's how long it takes.

Sample User Interface Sketches

I tend to work best starting by imagining a user utilizing the site. As this imaginary user navigates around I draw quick sketches of the pages they see and add any related comments that occur to me in the process.

I did a quick version for this project and so instead of spending any more time telling you about them... here are some sample scans. I tend to like the old pen and paper approach as you can see below. They don't need to be overly neat, but legible is nice and if you're working with a team you'll probably want something done on a computer just for ease of sharing and manipulation. Even a quick Windows Paint Bitmap can be quite useful in getting some broad strokes down to be sure everyone is on the same page as to what the end product will look like. The level of detail is up to you, but the more thought and detail you cover now the fewer surprizes you'll run into later.

Sample Sketches (Click To Zoom In):

Basic Page Layout Sketch Movie and Actor Pages Sketch User Rating Pages Sketch Login and Admin Pages Sketch

Another type of sketch that can be extremely helpful is a flowchart of the steps involved in a given process. For example, adding a comment to a movie might look something like this:

Review Flow Sketch

Database Brainstorming

Now that we've got an idea what the end product should look like, we need to get an idea of how we get to it. Since this app is basically all about the data... I'm going to tackle that next.

The main tables we'll need will obviously need to include: Movie, Actor, Genre, User, Reviews.

Just getting started... Movies can have multiple Actors, Genres, and Reviews. Actors can be in multiple Movies. Reviews are associated with a User as well as a Movie. etc...

We'll want to cover this in a lot more detail so I'm planning on giving the DB design full coverage in the upcoming weeks. At this point I've included it just to get you thinking about what information is going to go where was you think about the features and requirements.

The Multi-tier Approach

We mentioned in the idea section that we'll be building a multi-tier application. After getting some questions about this I realized that a number of our readers have probably never looked at their web site in this manner before. While I obviously can't cover the concept completely, I thought a breif run through the main concepts might be in order.

The three main layers in classic application design are the Data Services, Business Logic, and Presentation Layer. Their names are pretty self explanatory. The concept is that the code dealing with each section stays in that section. This approach has many benefits.

The first main benefit is that this approach allows you to easily deploy you solution across multiple machines by placing each layer on it's own machine (or cluster of machines). This is extremely beneficial when your application needs to scale to multiple servers. It allows you to tailor and tune each machine to the work it will be doing. The clustering of a particular layer allows you to add or modify machines to that layer without necessariy taking down the service. That way you can perform maintenence or upgrades to one layer without disrupting the others or the users using your application.

Code maintenence is another major benefit. As I mentioned above, clustering each layer allows you to isolate components at runtime, but probably even more important is the fact that all the code to deal with each particular facet of your app is all located in one place. For example, let's assume you've been told that you need to switch your web site from Access to SQL Server. The way most users build their ASP pages, that would mean going in and trying to find all the SQL statements in your web pages. If all the DB access had been controlled via one component, all the changes that needed to be made would be isolated to that component and your asp pages (the presentation layer) would need minimal changes (if any) to make the change. The transition would be much easier. Likewise if you decide to get a new graphic designer to give your site a facelift should they (or you) really have to deal with looking though all your DB code to see if you've got any html formatting in there that might need to be changed?

That in a nutshell is the concept behind multi-tier applications. I'm obviously over-simplfying things for the sake of brevity, but that's the basic idea and we're going to be using that approach in this app for two reasons. First because many of our visitors haven't seen it before and second because .NET makes it easier to do then it has ever been before.

Time to Rest

We've covered a lot today... I think that's probably enough for now. We'll be back soon with some more design specs and discussion and very soon now we'll even get to see some code! For now think about the DB design and remember that it's still not too late to send in feedback for the project.

Oh and if there's any interest in the original sketches signed and numbered by the artist himself, we'll be auctioning them off with all proceeds benefiting the ASP 101 Beer Fund! ;)

Project Links

Building an ASP.NET App: John's DVD Catalog
Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback
The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers