1

Given a layered architecture consisting of

  • presentation layer
  • business logic layer
  • data (access) layer

and a SPA web application communicating through REST endpoints with the backend (eg Angular and Spring), what would the presentation layer in such an application consist of? Would it only contain the stuff related to Angular? If so, what layer do the Spring rest controllers belong to?

When browsing the web, I realised that there seems to be some kind of ambiguity related to this topic. In most cases, the "presentation layer" is referred to as presentation in terms of visual presentation only, ie UI, which makes sense (at least somehow). In that case, the rest endpoints would belong to the business logic layer, which seems odd to me.

Maybe somebody can clear up my confusion.

Thanks.

2 Answers 2

1

A presentation layer is a presentation layer regardless of how the rest of your app is built.

You mention single page web apps (spa), rest, angular, spring, n-tier, etc. but a presentation layers job is still the same: combine data with a way to consume it.

That might be visual, auditory, or even tactile. It might be a GUI, a console, printed paper, plotter, web, an audio speaker, IP socket, or a fireworks display.

Each of those has needs that don’t need to be represented in the model. The presentation layers job is to transform data from the model into something that meets those needs.

Thanks to having a presentation layer the model can be free of knowledge of how data is presented. Ideally the same model can be presented many ways.

Presentation differences can be more than media. Key value pairs can be converted to graphical displays showing named positions on a map. Both forms could be presented to a GUI, a print out, or even a console (with a little ascii art).

The back end tech doesn’t change any of this. It does make some forms easier than others but the basic idea remains the same.

7
  • So where does this place the REST Api?
    – Rik D
    Commented Aug 4, 2020 at 18:39
  • @RikD a rest api is just another way to talk. Whatever is said thru it is presented somehow. But what it is finally presented to can be presented many different ways. Commented Aug 4, 2020 at 18:42
  • I assumed as much, but good to make it explicit. So if the REST Api is the presentation layer for the backend application, do you agree the frontend (in this case an Angular SPA) is a separate application with it’s own layers?
    – Rik D
    Commented Aug 4, 2020 at 18:50
  • @RikD it certainly can be. Commented Aug 4, 2020 at 18:53
  • This might be why the TS is confused. What are the boundaries of an application? Does the decision to communicate with the backend over HTTP instead of objects in memory automatically imply multiple applications? I think it does, but some might say that functional boundaries define an application.
    – Rik D
    Commented Aug 4, 2020 at 19:06
1

There are different understandings of the presentation layer.

The traditional layered architecture that you describe predates the internet and in fact originates from the three tier architecture model. In this view:

  • the presentation layer corresponds to the client component that offers the user interface and communicates with a backend which runs on an application server.
  • the rest API is the interface between presentation and business logic. The consuming part of the interface belongs to presentation. The producing part of the interface belongs to the business logic. It’s the service sublayer that exposes the business layer to the outside world.

The more recent MVP architecture is an adaptation of MVC that was triggered directly by the emergence of the internet. It sees it differently:

  • the business logic is part of the M (model) and the DAL is a sublayer of M that ensures persistance.
  • the font-end user-interface is the V (View) for the displaying
  • the P (presentation) is the component in the middle, designed to be split between front-ent where it takes charge of the user-input (similar to an MVC controller) and the queries (coming from V), and the back-end (where it dialogues with M, and acts as a local controller and as a proxy for the remote V and C). In this analysis, the REST API belongs completely to the presentation component.

MVP is not mutually exclusive with layering: M is in general layered in order to distinguish the BLL and the DAL, but in this case there is an ambiguity about what the presentation really refers to.

You are therefore free to decide in which layer you want to see your REST API.

Personally if I’d use a classical layer scheme to describe my architecture, I’d prefer to be consistent and split it according to the three-tier decomposition.

But, if you consider your REST API to be part of the presentation, because it already presents the data in HTML, you’d not be wrong: you’d just analyse it according to an MVP decomposition of responsibilities. But I’d then advise to make a clean cut between the back-end and the front-end part of the P, and to ensure a clear separation of very different concerns.

Not related: another question is whether you want to continue to see the world in classical layers, or if you’d prefer a cleaner architecture

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.