A layered architecture versus a non-layered architecture

Not every application needs to be built in a heavily layered manner. Not every application needs to be overly extensible. Some applications need to be built quickly and simply for the sole purpose of getting them out the door. However, be careful not to build something simple when something flexible should have been built in its place. While you can easily grow an application that was built with growth in mind, extending an application that was built without growth in mind can be difficult, if not near impossible.

Knowing that our application is going to be a large undertaking that should last for some time, we need to design something that can be easily extended as the need arises. For that we will try to design this application with extensibility in mind. The easiest way to do that is to follow the general rule of maintaining "separation of concerns".

Note

Separation of concerns (SoC) is the process of breaking down your application into specific units of functionality in such a way that each unit only addresses the need of one concern with as little overlap as possible with other units in terms of functionality. Look here for more information regarding this topic: http://en.wikipedia.org/wiki/Separation_of_concerns

Layers

The easiest way to maintain SoC is to first break major areas of your application into layers. In most applications, this might be broken down into the presentation, business logic, and data access layers.

  • Presentation: This layer would normally hold anything pertaining to the user interface of your application—the buttons, links, and other controls that a user would click on and interact with while using your application.
  • Business Logic: This is where the rules of your application would live. This could be as simple as formatting the currency of a price in your product catalog to something more complex such as enforcing rules regarding data input.
  • Data Access: The data access layer is responsible for connecting to a data source and interacting with the data that is stored in that location. This could be a database, some XML files, text files, or even a web service.

    Note

    There is a common argument amongst enterprise developers regarding the use of layers. It says something along the lines of "the more the objects in use, the more the resources in use". This is of course a true statement. However, the use of more resources in this case does come with a benefit in the form of greater flexibility in your application. Layers promote SoC as well, which directly benefits the developer as the physical code is easier to understand and work with.

I used to think that just these three layers were good enough and used them in several applications. However, I always found myself wanting more control in my application. Recently I worked on a project that expanded on these very common layers (into more layers of course) with the use of Domain-driven Design.

上一章目录下一章