How many layers is too many?

Question

As I have been learning about software development the last 2 years the more I learn, it seems the more gray areas I am running into. One gray area I have issues with right now is trying to decide how many layers an application should have. For example, in a WPF MVVM application what fashion of layering is ok? Is the following too separated? When I mention layering I mean creating a new class library for each layer.

• Presentation (View)
• View Model
• Business Layer
• Data Access
• Model Layer
• Utility Layer

Or for a non MVVM application is this too separated?

• Presenation
• Business
• Data Access
• Model Layer
• Utility Layer

Is acceptable to run layers together and just create folders for each layer? Any coloring of this gray area would be appreciated.

Answer 1

The answer is, it depends. First off, a separate class library doesn't always mean a separate "layer." A layer is a conceptual grouping of related functionality, that may or may not manifest itself in a single assembly.

How many layers you create is really dependent on your problem at hand. Traditionally, a WPF MVVM application will contain at least the 3 layers (Model, View, View Model) but it can really be varied. Often times I see the Views and ViewModels in the same assembly and the models in their own assembly (usually because the Model objects are POCO's that are used in other contexts)

There is really no silver bullet that answers your question, it is entirely dependent on your problem. The advantage of "layering" and separation is to increase maintainability, promote code re-use, and increase overall clarity (to name a few).

I would argue that if you are not reaching these goals with your current layering solution then you have room to improve. If increasing the layers is decreasing the clarity or maintainability then you have gone too far. If you have only a single "layer" and it is becoming bloated then you have an opportunity to add a layer.

The bottom line is don't over engineer something for the sake of following a strict "pattern." If the pattern has clear advantages to you and your problem at hand then implement it, but understand why you are doing so and what the goal of each "layer" is.

Answer 2

Consider the following areas:

• Speed
• Reusability
• Readability
• Development time
• Modification speed (the right words to describe this point are escaping me. Edit - Maintainability was what I was looking for [stolen from someone elses answer])
• Application footprint (scale and literal size)
• Your development team

...then adjust your architecture based on which of these you value. I'm probably missing some other important parts, but you get the idea. There's really no right or wrong answer to this.

Answer 3

An application only has too many layers if the layers themselves become a hurdle to the maintainability of the project as opposed to improving maintainability.

Answer 4

I think you're confused. MVC isn't a layer.

MVC is a design pattern or software architecture. There's no such thing as a "Model Layer" or "Data Layer". Just computer code that deals with the model (logic), data (database), or view (UI/front-end). These aren't layers. And like Foovanadil mentioned, classes, libraries, etc are not (usually) layers either.

Are you thinking of Abstraction Layers? In that case, you base the number of abstraction layers in your application by looking at a couple of elements:

• How much granular low-level control do you truly need?
• What are the benefits (if any) of X or Y abstraction layer? Is the overhead worth it?
• Will your application be updated often? It's notoriously difficult to add new features to insanely low-level applications.

Answer 5

The exact number of layers that is too many is 1 more than is needed.

Answer 6

Layered Architecture: This article describes a concrete example architecture for .NET/WPF Rich Client Applications. Furthermore, the architecture shows in which layer you find the participants of the Model-View-ViewModel (MVVM) pattern.