Separation of Presentation layer from Business layer

Question

From an article i just read,

http://stackoverflow.com/questions/424675/ui-layer-abstraction

Well are there any setbacks to a full separation between the presentation layer and the business layer?

This question actually came from a problem of tracing the progress of a process (certain series of instructions) and updating a progress bar accordingly for example.

Now the only one who knows the actual progress is the process itself, and that is in the business layer. So if both layers are pretty separate, how can I reach the progress bar from within the business layer without stepping on the presentation layer's domain? Or at least return progress values to the presentation layer?

Answer 1

IMHO the dialog about seperating layers misses one key fact: While layers need to be seperated for many reasons, that doesn't mean they can't do things to make things eaiser for the other layers.

We had a similar requirement - a progress bar for a long-running business process. What we did was define progress-events in the business layer code. These events would be called at vairous times - percentages complete, for example - and 'someone' subscribed to them. In our case, it was the UI layer!

So the layers are seperated, but 'business' has to understand that someone might want to watch it!

Answer 2

Make the presentation layer query the business layer for progress status.

Answer 3

dependency injection.

IOW your presentation layer implements some business layer callback interface (hence dependencies are in the good direction: ui->biz) and registers to the business component at runtime. In that case the business component sends progress updates to its callback interface and does not care of "who" is listening.

Answer 4

An "inner" layer is able to call code in an "outer" layer, as long as the outer layer specifies what the callback code is. This can be expressed through objects, interface, delegates or function pointers, depending on the language.

void DoSomethingLengthy(string arg1, Action<double> progressCallback)
{
    // during the operation
    progressCallback(0.5); // halfway
}

DoSomethingLengthy("blah", progress => bar.Value = 100 * progress);

Answer 5

You should consider the "progress bar" as two separate pieces of logic as well.

The bar that the user sees is 100% presentation, and as such all logic to make it grow should be contained in the view.

Your business layer could they expose an "ProgressUpdated" event which simply fires every X percent.

The view would subscribe to said event, and display meaningfully on the UI.

Answer 6

Obviously the buisness layer must know what progress has been made. It must then either tell the presentation layer when progress has been made or the presentation layer must ask the business layer. Whichever you prefer.

The key point is that the presentation layer should not be making a judgement of what progress has been made and the buisness layer must not be deciding how to present the information to the user.

Regards

Answer 7

Another one I've found is that the metadata of the business layer - e.g. field lengths and uniqueness in a database - are stuff that presentation layers need to know about.

You can either export it from the business layer or have it in a common module that the two share, but it's important you don't end up duplicating the same information in the business layer as database field lengths and in the presentation layer as input constraints.