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.

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.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at

comments powered by Disqus


  • GitLab Takes Over VS Code Extension, Plans Improvements

    DevOps specialist GitLab has officially taken over the control of a GitLab extension for Microsoft's open source, cross-platform Visual Studio Code editor.

  • VS Code Python Tool Now Does Native Notebooks

    The Python Extension for VS Code Insiders team is previewing the newest implementation of notebooks, used frequently in data science with offerings such as Jupyter Notebooks.

  • As .NET 5 Nears, Content/Documentation Reorganization Starts

    A GitHub project is seeking to reorganize documentation and developer content in advance of the November debut of .NET 5, a unification of all things .NET that combines. .NET Core and other components.

  • Windows Devs Get Cross-Platform Page, Issues Repo

    Developers doing their coding on the Windows OS have received two new resource gifts from Microsoft: a new landing page for those using cross-platform technologies and a new GitHub repo with which to report issues to Windows engineering teams.Developers doing their coding on the Windows OS have received two new resource gifts from Microsoft: a new landing page for those using cross-platform technologies and a new GitHub repo with which to report issues to Windows engineering teams.

  • What's New in Entity Framework Core 5.0 Preview 7

    Microsoft shipped the seventh preview of Entity Framework Core 5.0, boosting its data access technology with a factory to create DbContext instances and more.

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events