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 http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • What's New in Visual Studio 2019 v16.5 Preview 2

    The second preview of Visual Studio 2019 v16.5 has arrived with improvements across the flagship IDE, including the core experience and different development areas such as C++, Python, web, mobile and so on.

  • C# Shows Strong in Tech Skills Reports

    Microsoft's C# programming language continues to show strong in tech industry skills reports, with the most recent examples coming from a skills testing company and a training company.

  • Color Shards

    Sharing Data and Splitting Components in Blazor

    ASP.NET Core Version 3.1 has at least two major changes that you'll want to take advantage of. Well, Peter thinks you will. Depending on your background, your response to one of them may be a resounding “meh.”

  • Architecture Small Graphic

    Microsoft Ships Preview SDK, Guidance for New Dual-Screen Mobile Era

    Microsoft announced a new SDK and developer guidance for dealing with the new dual-screen mobile era, ushered in by the advent of ultra-portable devices such as the Surface Duo.

  • How to Create a Machine Learning Decision Tree Classifier Using C#

    After earlier explaining how to compute disorder and split data in his exploration of machine learning decision tree classifiers, resident data scientist Dr. James McCaffrey of Microsoft Research now shows how to use the splitting and disorder code to create a working decision tree classifier.

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events