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.
