Home » Software Development » Multilayered Architecture (5) – The Presentation Layer

About Marco Di Stefano

Marco is a software engineer specialized in software architecture and process automation. He has been involved in all the software v-cycle phases and actually he works for the railway industry.

Multilayered Architecture (5) – The Presentation Layer


The final piece of a MultiLayered Architecture, in term of development design and dependencies is the Presentation Layer. It has mainly the scope to create an Interface with the final User of the application. It can take the form of Desktop forms, Java Applet, Web application and any other possible solution provided by technologies.


At this stage, if all the other layers have been correctly designed, it will be very simple to create a Presentation Layer. Consider the case where the logic has to be distributed as a standalone application. In this case it will be great to integrate the created logic into a Rich Client Platform. Several good ones exist and I would like to remember the NetBeans Platform (actually my preferred one) and the Eclipse Platform.

But in another case it could be nice to deploy the application on the web, and so in that case all existing layers could be integrated with any web technology as JavaFX, GWT, JSF…

And in another case, why not use the same logic to be deployed both as desktop and web application? You just need to have a build of Domain-Application-Infrastructure layers to be bundled into two different Presentation implementation, and if overall design is enough good you will not need to duplicate any line of code.

Presentation Layer as an independent project

Clearly the Presentation Layer could be managed as an independent project. There are no constraints related to the moment where it has to start, the only constraint is that it must never influence the design and development of all the other layers.

There are several efforts related to this:

  • Avoid Logic to UI coupling in all code residing in other layers. Actually this type of coupling is considered negative and dangerous as it affects directly the Testability of the designed software solution (as discussed in another post here)
  • Analyst responsible of UI design can be different from business analyst, and in my opinion it is preferable. To design UI the most important thing is to have graphic design knowledge, even if the business knowledge is not full. Ugly UI are typically caused by the bad choice to let developers design them (not agree…?)
  • Force developers to test code writing automated tests and not simulating user interactions. This actually is a very bad practice, to test logic we create the UI, we simulate the user interaction, and finally we agree that code is safe and tested. But what about automation? And what about code and requirements coverage?
  • Think at the logic implementation and not how nice it is presented. If developers working on business logic do not have access to any implemented UI they will be obliged to think simply at the code they are writing and not at the way it is presented. And probably this lack of presentation will be positively replaced by an increasing amount of design documentation that has to be provided to document and explain the code.
  • Different Technologies need different profiles, so probably will not be the same team that is responsible of different implementations


The Presentation Layer is very important for the user, as you cannot do any demo without it, but in this post I wanted to put the focus on the fact that it must not be so important also for the developers. One of the most common errors when developing a software solution is to start thinking how it will look like, once instead this should not worry too much analysts, architects and developers since a separate team could be in charge of developing it. If all other layers provide well defined boundaries and interfaces, then the Presentation Layer could even be implemented before that concrete implementation of those interfaces exist, using stubs, mocks or fake objects.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments