How to code .NET web applications from scratch without hurting yourself

Ok, first off, you never ever code anything from scratch unless you absolutely have to. Always leverage something you did in the past, be it a standard template test bed application, or a code generator tool you wrote. Starting from scratch for anything is daunting, so if you must, then break down the task.

Design the interface first

It might sound counterintuitive, but you should start from the end product. In this case, what the user would see on the screen. No amount of nifty programming tricks or beautifully categorised class files would do an iota of good, if the user cannot use the application properly.

You are starting from nothing. You are probably pressed for time. So when the user lands on a page, you want the user to do only one thing: the function the web page offers and only that.

Those flashy and cool applications with tons of options? Forget them. Multiple ways of performing a calculation? Forget them. If the user is supposed to save some data into the database, have only one save button on the page and make it prominent.

Draw out the design on paper. Shuffle TextBoxes, DropDownLists, Buttons and other web controls around. On paper. Make sure you’re satisfied with how it looks, and how the user is expected to interact with the web page. Position other elements such as headers/footers, maybe company logos.

This is especially important if you don’t have dedicated web designers. Moving design elements on paper is cheaper than moving them after you’ve coded hundred-line code files. If a design change fundamentally affects the code behind it, there’d be a lot of rewriting or refactoring to do. Laziness can creep in (or fierce defense of one’s code, regardless of its usefulness), and the design change never happens. And the user will be stuck with some unusable interface.

2 1/2 tier

You might have heard of multi-tiered (web) applications. There’s usually 3 tiers: user interface, business logic and data access. The idea is to separate the application into manageable chunks.

The user interface tier refers to the web page display, the HTML and web controls and validation logic. The code behind of the web page should only

  • Handle data display logic
  • Validate data and hand them over to the business logic
  • Do any display tricks with AJAX or special formatting

The business logic tier handles anything specific to the requirements of the application. Special validation rules, calculations or reformatting data structures are done here. This tier basically acts as a middleman between the user interface and the data access tier.

The data access tier takes care of retrieving data and storing data. Your selects, inserts, updates, deletes and other SQL commands should only appear here.

This separation helps compartmentalise specific duties. Imagine 3 different roles, web designer, programmer and database administrator.

  • The web designer can’t speak programming language, but is given functions such as GetLastProcessedDate().
  • The programmer gets the call of GetLastProcessedDate(), but doesn’t know how to get it from the database, so hands it over to the database administrator.
  • The database administrator finds the date, but don’t know how to format it for web designer, so hands it back to the programmer.
  • The programmer remembered the database date is in UTC, so does the appropriate calculations, and hands it back to the web designer in a string.
  • The web designer, ecstatic that the date is finally here, displays the date string in a beautifully designed Label.

Well, you are pressed for time, so you’re going to merge the latter two together. The business tier is going to work extra hard, and take care of database access as well. You are probably not going to host the 3 tiers in separate servers, so this’ll be fine. The main purpose is to separate visual display logic and business logic.

Data structures

Once you have the 2 (1/2) tiers, you need a standard way for the tiers to pass data back and forth. You have 3 choices:

  • DataReaders
  • DataSets and/or DataTables
  • Custom collection classes

DataReaders offer speed, but not much else. DataSets/DataTables offer more flexibility, but also more complexity. Custom collection classes offer the best of both worlds, but is hard to come up with a consistent code format.

I prefer custom collection classes, and I even wrote a small application to help me generate them. That small application has already paid itself several times over for the effort required to code it.

Assume that someone is going to hack your application

As an eccentric one-eyed professor of Harry Potter’s would say, “Constant vigilance!” This constant alert should be present at every single point of coding. Assume that the user can and will give weird input, and handle it. Assume somehow your flawless function is going to fail for an unforeseen situation, and handle it. Assume someone is going to hack your database, so use SQL parameters, and handle it.


So now you’ve designed your web application for the important aspects of usability, code manageability and security. All from scratch, and following the basic sound tenets of good programming practices. You invest the time and effort to do this well, and you’ll be able to come up with your next web application in a fraction of the time.

Comments are closed.