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.