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

Introduction

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.

Interchangeability

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

Conclusion

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 two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


one × = 9



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

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

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close