Practical ASP.NET

In Defense of Single-Tier Applications

You put all of your code in the code file of your ASP.NET pages -- but other developers keep kicking sand in your face because you're not doing n-tier development. Peter's here to say that you're not (necessarily) being dumb.

• By Peter Vogel
• 03/25/2010

I tend to build multi-tier applications with a layer of middle-tier business objects that are called from a little bit of code in my pages' code files. However, there are any number of ASP.NET developers who don't use that model. Instead, these developers put most of their code into their pages' code file.

I'm here to say: That's OK. There are three conditions that need to be in place before it will make sense for you to use a multi-tier development strategy.

Condition 1: Team Environment
The first condition is whether you're working in a team environment. One of the beauties of multi-tier development is that you can divide the application code up into several different code files and (though class libraries) into several different projects. As long as team members settle on what methods, properties and events each class will expose, developers can work more-or-less independently on the same application.

If you're working by yourself and you don't have much overlap in functionality between pages, then multi-tier development won't offer you much help. If you do have overlap in functionality (for instance, if customer data can be updated from several different pages), then there's a danger that those different pages will implement the functionality in different ways. Having a Customer object allows you to keep that code in one place and have it managed by one developer. Even if you're a lone developer, using class files like this can reduce the amount of duplicate copy-and-paste code in your application.

Condition 2: Complex Business Logic
The second condition to consider is whether you have to support complex business logic. As business logic becomes more complex, each If... Then statement you add doubles the number of paths through your application and increases the testing required. If, in addition, all testing must be done through the application's UI, testing becomes a bottleneck.

Object-oriented development (along with applying well-known design patterns) reduces this problem. Rather than a few big hunks of complex code, you end up with lots of simple objects that can be tested individually: logic is replaced with objects. But note that I said business logic. If most of your complex logic is related to workflow or handling the UI, then a single-tier model may still be valuable to you.

Closely related to this precondition is whether your application will see much modification and/or extension over the course of its life. Multi-tier applications are easier to extend and modify than single tier applications. For instance, if you've used the right design pattern you can often add new functionality just by dropping a new DLL into the application and modifying a single line of code. This is a non-benefit, however, if your application is static after its release.

Condition 3: Scalability
The third precondition is scalability. Using multi-tier development allows you to distribute your application over several different computers, letting you to throw more CPUs at performance problems. Data access is also centralized in a few objects, making it easier to optimize data access (the usual cause of poor performance).

I have to admit that I consider scalability to be the least important precondition, because (a) many scalability problems can be addressed by creating a Web farm and installing multiple copies of the same site on several different computers, and (b) ASP.NET is so darn fast that it may require hundreds of users simultaneously hitting their submit buttons to actually slow down your application to a critical point. How many sites have that problem?

I won't mention re-use as a benefit of multi-tier development because, quite frankly, it doesn't happen much. Social and political pressures within an organization usually limit re-use to a single team and a single application.

The only wrinkle in this set of preconditions is that you do need to worry about the future of your application. While all three of these preconditions are in place now, one or more of them may be violated in the future. In that case (and at that point) it would have been better to go with a multi-tier model from the start.

If you are a single-tier developer and are considering moving to multi-tier development, the next few Practical ASP.NET columns are for you: I'm going to walk through the process of creating objects that will integrate with the ObjectDataSource

.