|
A Sample Chapter from
|
ASP.NET Website Programming
|
|
|
|
Sample Chapter From
|
|
|
Maintaining the Site
Any real website is generally made up of a lot of pages,
images, XML/XSL files, stylesheets, databases, and other types of document.
It's very common to have many hundreds or even thousands of files for a single
website. During development of the site these files will usually be modified
several times. This will also continue after deployment, since no application
is ever really finished – particularly when we can redeploy to all our users at
once. As a result, an integral part of any
development work is having some kind of maintenance system.
In this chapter we'll explain why it's useful to have an
online site management system, and we'll design and build one that allows us to
easily maintain the site's files and directories.
Our solution will provide file uploads over HTTP
connections, a useful technique that is not limited to site maintenance. For
example, web-based e-mail sites use this method to upload attachments, and many
community sites use it to upload images for user profiles.
We will also build an online text editor, so that we can
edit our ASPX files right in the web browser.
Our tools will really be for administrators or developers to
use. But with a simplified, restricted front-end we could use this technique to
build a maintenance system for even the most
technically inept client!
We will also present an
existing third party tool, Microsoft's Web Data Administrator.This
could save our developers a great deal of time managing the site's SQL Server
database, both before and
after deployment.
The Problem
During the development of our site, we'll need to add, copy,
and move files, change the source code of ASP.NET pages, edit the stylesheets,
and generally fix things here and there. Since we're working on a test machine,
and as we're all familiar with doing such common operations, this
does not pose any problems. Managing the SQL Server database is easy as well,
because even if we don't have the program installed on our development machine,
through the Enterprise Manager we can do everything we could if we had the SQL
Server on our local computer.
After development will come the time to upload everything and
to test the website online. We'll almost certainly need to make further
changes, upload additions, move files around, and perform other file management
operations. The same applies to the database: we'll need to add, edit, or
delete records, run and edit stored procedures, and backup the data. If we had
an in-house server, we wouldn't expect to encounter any problems here, as we
would just need to move everything to the production system. Maintaining the
site would be as easy as it was on our development machine. Having an in-house
server offers maximum control over the system, and this is important when we
need to install additional software, register COM+ components, change the IIS
default settings, and so on – in fact, whenever we want to configure things
according to our needs. However,
often we do not require all this power, especially for small and medium sized
sites. Also, with ASP.NET, deployment and configuration has been made much
easier and flexible (take for example the use of web.config
to change settings that would previously have required direct access to an IIS
snap-in in ASP). Lastly, in-house or dedicated servers are expensive, and not
all companies can and/or want to afford them, unless their purpose is very
unusual.
Therefore, if we have budget limitations or we simply don't need full control over
the system, the common solution for publishing our website is to a rent a shared server from a hosting company.
We decided to choose this solution for our website, because we don't really
need a deep level of system customization – web.config settings are enough for
this. Also, we wanted to present an example that would be useful to the
majority of readers, and that means using shared hosting.
