UI Layer Abstraction

Question

I have successfully worked with abstracting data layers and business layers. But recently a colleague mentioned about abstracting UI layer- in between the UI and the business layer. However I cannot get my head around it. I cannot visualize how this UI layer will be different from the business layer. I have goggled enough for articles and dont seem to find much help. Can someone tell me a simple example?

Answer 1

There are multiple options here.

1. MVC

   You need to separate the View away from the Model and Controller. The easiest way to imagine why you would do this is if you had the same Model and Controller that you wanted to present different views to - the website view, the stand-alone application view, the web-service view, the mobile phone view, your unit test views, etc. Therefore you want no logic in your view code. I.e., in Java, no model manipulation inside your ActionListeners and other GUI code - instead you move that out into a controller class, and the View handler simply does input validation, output formatting, and talks to the controller class.

   Many views are written from a view-centric approach. You have your GUI. Something happens, and you react to that and do stuff, and update the GUI as necessary. Therefore it's easy to tie your business logic and model very tightly into the view.

   Basically, you create (an) interface(s) into your business logic that anything can call, thus adding new views is simple. Those interfaces provide all of the functions that you need to call. You can then make the internal business logic private.

2. The data gathering webform (or series of webforms)

   It is highly unlikely that you will want to gather information in the same order as your data model in your business layer. In addition you will need to persist between pages in the multi-page form. You will rapidly find that those not null constraints are a PITA when you are gathering them on page 3 (because they put customers off on page 1). Because the forms are liable to change as they get rearranged, you'll end up separating the business logic from the view pretty early on, and generalising how you populate your model. And lots of other stuff.

3. The interface that is generated from the model

   You have a model that can change, or indeed describes an interface either explicitly or implicitly. You therefore generate the interface from the model instead of using pre-designed forms and windows and so on. This way you have to program your view code quite generically as you will only have the model to work from. Lots of maps from model to UI and vice-versa. Then you add in some observers because the model values change elsewhere, and it's great fun... :)

4. Something else ...

Answer 2

I found Jeremy Miller's Build Your Own CAB series of articles very informative in the past. He describes many variations on the Model-View-Controller family of patterns. It is an excellent read.