Isolating business logic from presentation logic

I sent this request to the VBDNOTNET and DOTNET-WINFORMS mailing lists. I’ll try to update as I get feedback on this topic.

I’m pondering what will be necessary to migrate our current VB6 architecture
to VB.NET. One area that is stumping me is classifying “business logic” and
“presentation logic”. One interaction that is stumping me is when the
presentation layer has constraints or side effects due to what I would
consider business rules. I’m not good at describing things abstractly, so
let me use a concrete, simplified example from our application.

One of the maintenance forms in the application involves entering and
maintaining sales order line items. One portion of the user interface allows
the user to control how a particular item is going to be sent to the
customer. From a business perspective, three scenarios are possible.

o Ship the item from the primary warehouse associated with location taking
the order.
o Ship the item from a branch warehouse directly to the customer.
o Transfer the item from the branch warehouse to the primary warehouse.

One way of implementing this in the user interface is with two fields:
o Combo box to select the appropriate scenario from above
o Text box to select the ID for the warehouse.

In the first scenario, the text box value is defaulted and it should be
disabled. In the other scenarios, the textbox is enabled.

The presentation layer must have code to set the Enabled property of the
textbox. The question is where should the condition checking code go?

One possible solution (sort of the way we’re doing it now):
Put code in the presentation layer…
Private Sub Combo1_Click()
If Combo1.ItemData(Combo1.ListIndex) = “SELF” Then
Combo1.Enabled = False
Else
Combo1.Enabled = True
End If
End Sub

My concern with this is that it seems to be putting business logic into the
presentation layer by virtue of having the reference to “SELF” in the code.
Is this considered a mix of business logic and presentation logic?

Another solution I have considered:
Design a generic interface between the business data and the presentation.
For example, each data field could have an Editable property. The
presentation layer code would be something like this:
If BusinessObject1.Fields(Control1.DataField).Editable Then
Control1.Enabled = True
Else
Control1.Enabled = False
End If

What I like about this:
The code in the presentation layer is generic. With VB.NET Delegates, I can
envision having one delegate wired to all the controls or to controls of a
certain type. Designing the presentation layer could be as simple as
dropping a control on a form, naming it, and setting the DataField property.
Perhaps also the datasource would need to be defined if a form uses multiple
business objects.

In my view, the business logic is completely encapsulated in the business
layer. The reference to “SELF” is inside the business object and it controls
the Editable property of the field.

What I don’t like about this:
I have concerns about performance. Every edit in the presentation layer
needs to be submitted to the business object in case there are side effects.
The presentation layer has to completely refresh itself each time or be
provided a list of changed properties from which to refresh the display.

The business objects are typically residing in COM+. The chatty nature of
this design would be a performance concern to me.

If I want to avoid maintaining state in COM+, which I think is a worthy
goal, we have to be able to transfer state between the business layer and
the presentation layer. This is even more overhead to be passing back and
forth.

If extensions need to be made to the user interface, they may have to be
made to the business object as well. For example, we recently added the
ability to display certain controls differently when they are outside
established business guidelines. For example, if the price is too low or too
high, the presentation layer needs to show it differently. Using this second
design, we would need to add another property to the business object data
fields (e.g. a boolean called “Alert”) which the presentation layer can then
interpret.

I’m interested in hearing other people’s ideas and opinions. Have you
struggled with these same questions? Do you know of any good resources that
cover these kinds of specifics? Is there another kind of solution I haven’t
considered?

Advertisements
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: