R – Separation of Presentation layer from Business layer

Architecture

From an article i just read,

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?

Best Answer

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!

Related Solutions

Isolate the domain entities from the presentation layer

Quite simply, the reason is one of implementation and drift. Yes, your presentation layer needs to know about your business objects to be able to represent them properly. Yes, initially it looks like there is a lot of overlap between the implementation of the two types of objects. The problem is, as time goes on, things get added on both sides. Presentation changes, and the needs of the presentation layer evolve to include things that are completely independent of your business layer (color, for example). Meanwhile, your domain objects change over time, and if you don't have appropriate decoupling from your interface, you run the risk of screwing up your interface layer by making seemingly benign changes to your business objects.

Personally, I believe the best way to approach things is through the strictly enforced interface paradigm; that is, your business object layer exposes an interface that is the only way that it can be communicated with; no implementation details (i.e. domain objects) about the interface are exposed. Yes, this means that you have to implement your domain objects in two locations; your interface layer and in your BO layer. But that reimplementation, while it may initially seem like extra work, helps enforce the decoupling that will save TONS of work at some point in the future.

Asp – html helpers ASP.NET MVC DropDownList in .aspx in VB language

Thanks TV for pointing me in the right direction... I struggled with nutting the array Constructer Type in VB - It was right there all the time....

Robert's on page 26 of Steven Sanderson's great book, Pro ASP.NET MVC Framework.

Many thanks.

Gordon

<% Using Html.BeginForm()%>
    <p>Your name: <%=Html.TextBox("Name")%></p>
    <p>Your email: <%=Html.TextBox("Email")%></p>
    <p>Your phone: <%=Html.TextBox("Phone")%></p>
    <p>
        Will you attend?
        <%=Html.DropDownList("WillAttend", New SelectListItem() { _
           New SelectListItem With {.Text = "Yes, I'll be there", .Value = Boolean.TrueString}, _
           New SelectListItem With {.Text = "No, I can't come", .Value = Boolean.FalseString} _
           }, "Choose an option")%>
    </p>
    <input  type="submit" value="Submit RSVP" /> 

<% End Using%>

Best Answer

Related Solutions

Isolate the domain entities from the presentation layer

Asp – html helpers ASP.NET MVC DropDownList in .aspx in VB language

Related Topic