Practical .NET

Shedding Tiers: Stop Thinking in Terms of Layers

Thinking in terms of layers or tiers really isn't much help to you. Stop doing it: The single responsibility principle and design patterns are all you really need.

• By Peter Vogel
• 06/12/2014

Now that the Entity Framework (EF) has replaced almost all of what used to be called the data access layer (DAL) -- code that converted rows into objects and converted changes to objects into SQL statements -- it's odd to find designers still trying to define part of their application as a DAL. Those developers seem to feel their application has to have a DAL and they just need to figure out where it is. I don't think those layers exist. In fact, the more current conceptual tools (design patterns and the single responsibility principle, for example) provide far better guidance about how to divide up your code than the layers paradigm ever did.

History's Dead Hand
Part of the reason layers and tiers exist is historical: In the days of client-server computing, you had to figure out what you were going to install on each physical computer. The idea of tiers integrated two ideas: Classes in a layer communicated among themselves because all the classes in a tier were all on one computer; classes in a layer made restricted calls to classes in another tier because those other classes resided on a different computer. Tiers then got extended into logical layers and kept hanging around as, presumably, a useful design tool. But in an era of interconnected systems (thank you very much, Web Services and the cloud), that paradigm isn't much help any more.

These days, when I'm solving a particular problem, I look for a design pattern that will give me a solution with characteristics I value. The issue of "Into what layer do the classes that make up the pattern fall?" simply doesn't come up. If such a fundamental tool as design patterns ignores the issue of layers or tiers, you have to wonder what layers and tiers bring to the party.

There are other approaches to layers. For instance, in his excellent book, "Code Complete: A Practical Handbook of Software Construction, Second Edition" (Microsoft Press, 2004), Steve McConnell recommends "stratification": levels that give you a consistent view of your application and allow you to dip into other, deeper levels only when needed. The example he uses to demonstrate stratification is, effectively, an implementation of the Façade pattern. If you have the Façade pattern, why do you need stratification?

How We Do Things Now
That's not to say you don't need some categorization scheme. One of the results of applying the single responsibility principle is that you end up with a lot of classes. You need some way to organize your classes so that you can think about them and talk about them with other developers. However, that probably means you need several different categorization schemes, which you apply at different times for different purposes.

For instance, you talk about the classes that Pat's team is maintaining, and you organize those classes to take best advantage of the team's expertise and to simplify the team's life. Some categories are imposed upon you by the current technology, so you talk about JavaScript classes and Web Service classes.

You talk about classes in terms of the business activity they support: the SalesOrder classes. You talk about how to construct classes to reduce work, and you organize those classes into class libraries to support the way code will be shared among projects. Sometimes you talk about all of these categories at once: Pat's responsible for maintaining the base JavaScript classes used in processing sales orders in several applications. But "layers"? Not so much.

Some categories will correspond to the old layers and tiers and will tempt you to start thinking that way again (is your JavaScript code part of a "presentation layer"?). But you'll resist that (no, my JavaScript code is made up of classes doing a wide variety of interesting things). Why won't you go looking for layers? Three words: They. Don't. Exist. It's just classes talking to each other.

No layers, no tears.