UI Architectures with JSF Andy Bosch, www.jsf-academy.com

Agenda

• Why should we talk about UI architecture?

• Technology and architecture – how does that fit together?

• Design principles and design patterns

• Concepts and ideals for an UI architecture (based on JSF)

• Conclusion

About myself

• Name: Andy Bosch • Freelance IT architect, trainer, developer, … • Own training programme for JSF, CDI and Portlets

• Focus on JSF, Portlets and “related technologies” • Member of the Expert Group for JSR-301, JSR-329, and JSR-344 (JSF 2.2)

• Editor and trainer on www.jsf-academy.com

Our big goal

• Realise the UI layer based on a stable and sensible overall architecture

• The UI layer should smoothly fit into the overall architecture

UI and architecture?

• „UI, aren‘t that just colourful pixels!”

• “There is no programming regarding UI, only painting and graphical design. Why should I need an architecture here?”

• “Hey you, frontend guys. Let the “real men” do the architecture!”

UI and architecture? Yes indeed!

• The UI layer is a separate layer within an overall architecture.

• In a UI layer happens much more than you might probably think: • Bean handling • Page flow • Conversion and validation • Visualisation of errors • Calling the service layer • Processing the response of the service call

The frontend of the frontend

• When talking about frontends, misunderstandings often arise. • Reason for that: There is a frontend of the frontend and a backend of the frontend ;-)

• JSF is predominant in the backend of the frontend.

• (Are you now entirely perplexed?)

Frontend-Frontend

• Webdesign

• Html / Html5

• CSS

• Images, font

• Partly JavaScript as well

Backend-Frontend

• Processing on the server side

• Conversion and validation

• Management of beans

• Model updates

• Service calls

UI architecture in the backend-frontend

• Backend-frontend: This is where the action takes place.

• In the backend-frontend, the transfer from UI to service happens (and vice versa of course).

• Regarding JSF, everything happens on the server (not in the browser).

à For this part, we need a good UI architecture.

Well, get to the point: How do I start?

•  How can I build a good UI architecture?

•  Where should I start?

à Best recommendation ever: Start as soon as possible thinking about that. Do not start when it is too late.

Software design principles as a starter

• Separation of concerns • Each class has its specific responsibility and can be clearly separated from other classes

• DRY / DIE • No code duplication

• Loose coupling • Various software components are to be arranged so that changes can be easily applied and no tight coupling exists

Design Patterns - the next step

• MVC - Model View Controller MVP - Model View Presenter

• Sandbox pattern

• Facade

• Blackboard pattern

Very basically: Overall architecture

UI  layer  

Service  layer  

Backend  layer  

Architecture and technologies

• Technology is not an architecture!

•  But technologies can help you forming an architecture.

•  Some technologies clearly can be assigned to a specific layer.

Overall architecture with technologies

UI  layer  

Service  layer  

Backend  layer  

JSF  GWT  

Wicket  

Spring  IoC  (!?)  

CDI    (!?)  

JPA  

Hibernate  

Patterns in the UI layer

• MVC • Model View Controller pattern • Realises the principle of separation of concerns • Specialised artefacts for the model, the view, and the controller

• MVP • Model View Presenter pattern • MVC is the basis, except for the M and the V being completely separated from each other

• The presenter controls the entire processing logic (control model, fill view, …)

JSF and MVC

• JSF only knows managed beans

• The specification says nothing about controller or models

à Well, then let us do it: We create a model-managed bean and a controller-managed bean

à You can perfectly realize a clean MVC with JSF.

Functionality in the model?

Why do I have to distinguish between a model and a controller? • Separation of concerns • Clarity, maintenance

•  But also: central exception handling (sandboxing)

Recommendation: MVC in JSF

UI  layer  

Service  layer  

Backend  layer  

M  

V    C  

Exception handling in JSF

• JSF 1.x: No central spot / class available.

à Try / catch in phase 5 (invoke application) à Sandboxing approach

à Never ever functionality in the model (catchword lazy loading); who could ever catch an exception here?

• JSF 2.x: central exception handler available

Recommendation: Sandboxing in “C”

UI  layer  

Service  layer  

Backend  layer  

M  

V    C  

Calling the service layer

• Domain specific tasks are not (emphasis on “not”) part of the UI layer, but of the service layer

• You can call the service layer by • Simple method call • Web service call (SOAP) • REST • Remoting (RMI, HttpInvoker, …)

• Response • Exceptions? Checked? Unchecked? • Return object • Simple data object?

From JSF to the service layer

• Call should happen only in phase 5 (invoke application)

• Or is this wrong? Can I not call the service lazy in getter-methods? (ugh ...).

• Call in ValueChangelistener? Triggered by system events?

à Recommendation: Define clear and strict call points. No spaghetti by calling the service from the UI.

Spaghetti from the UI to the service

UI  controller  

ValueChangeListener  

XHtml  page  

GeGer  method  SystemEvent  

Service  layer  

Don’t  do  it  this  way!  

Recommendation: Service call starting from “C”

UI  layer  

Service  layer  

Backend  layer  

M  

V    C  

Service  

How to realise the service call

• Local method call?

• Injection via CDI?

• Remote call? REST or SOAP?

•  What does the response look like?

Recommendation: -  Clear and strict separation and decoupling

Status: So far so good ...

UI  layer  

Service  layer  

Backend  layer  

M  

V    C  

Service  

Another issue: Let‘s talk about the model

• Is the M in MVC a plain view model?

•  Or is it a database entity that I should pass from the database onto the UI?

• DTO’s?

• Detached or attached objects in the UI?

Where is the model?

UI  layer  

Service  layer  

Backend  layer   Person  

Working on detached objects

•  Load using JPA •  Detach it and return it to JSF

à Entities can have relations. Should these relations be called immediately?

à Load everything over all relations? à Or just return “null” for relations?

Working on attached objects

• Servlet filter Open the database session in a filter. Common practice is to open and close it before and after the JSF request.

à  OpenSessionInView pattern à  Does anyone have control over the generated SQL statements? à  Separation of the layers?

Classic approach: DTOs

• A lower layer loads all necessary data

• Data will be packed in a specific “format” or “structure”

• This “structure” (DTO) will be returned to the UI

• Martin Fowler calls them domain objects and presentation objects

One possible result

UI  layer  

Service  layer  

Backend  layer  

M  

V   C  

PersonEnLty  

PersonDTO  

Conclusion

• UI architecture is a very important topic.

• And now WE know: UI architecture exists. It is not just talking about pictures.

• There are different approaches to solve the problems. But it is important to know and understand the various approaches in detail.

Questions?

You can write an e-mail to andy.bosch@jsf-academy.com Twitter @andybosch Web www.jsf-academy.com