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. ;)
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):
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:
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.
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
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! ;)