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

In simplest terms, your UI layer only concerns itself with the UI and collaborating with the next level down (your business layer possibly). Your business layer and data layer (and any other layers you have) should never have any UI code in them because it's the UI layers job.

Think of the way a web browser works, the browser is the UI layer and concerns itself with rendering your page and nothing else. When something needs to happen it makes a call to the web server (the next layer) to do this and then renders the results.

Try googling for some well known UI patterns:

MVC

MVP

The Humble Dialog Box

Answer 2

I have read about the MVC,MVP and Humble Dialog Box.(i was pullign my hair out). The colleague who mentioned UI layer was not able to give me a very good example of how it differs from the business layer. And when asked he said it was not MVC/MVP. Hence I thought I would ask around

Answer 3

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 4

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.

Answer 5

Here's my principle: if you have to re-write any logic (other than manipulating form controls), then you haven't fully separated the UI layer from your other layers. Personally, I like to have a Service layer that holds my business rules, manipulating domain and datamapping objects, and only exchanging domain objects with the UI. The UI doesn't know anything about datamapping then, or about business rules.

That doesn't answer about a separate "UI layer" between UI and my Service layer. Perhaps this is in terms of keeping HTML and code separate (i.e. ASP.Net's code behinds might be considered a UI layer). There's nothing worse (in changing/debugging web apps) than having to change global HTML settings when the markup is built piecemeal in a thousand different functions. HTML should just be in HTML files with the minimum amount of scripting required to relate them to classes.