n-Tier and separation of UI from business logic?

[Rob R. Ainscough]

I understand and implement the concept (as best I can), BUT what I would
like to know -- how is it possible to completely remove the UI from business
logic? "UI references business logic, but business logic should never
reference UI."

For example, a process that cycles thru datarows in a datatable where after
each iteration the UI progress bar needs to be updated (to show a user that
something is going on)? To truely remove the business logic from the UI, I
can't reference a progress bar control as that is UI and hence invalidates
the concept.

The only way around this is to NOT provide a very accurate progress bar or
display some animation graphic or use an event timer that turns on and off
when the business logic starts/finishes -- but in all cases this is not a
very accurate representation of the duration of a particular process.
Having looked at some of Microsoft's products (Windows Defender Beta 2 for
example) they don't even attempt to portray any accuracy -- just an
animation that the process is still running.

So, I'm curious how you folks resolve this conflict of concept and retain
any accuracy in the state of progress for those long running tasks?

Rob.

 

[Jared]

It sounds like you need your business layer to raise some events. Then
your UI can optionally hook into those events to show a very accurate
progress bar.

 

[Mehdi]

I understand and implement the concept (as best I can), BUT what I would
like to know -- how is it possible to completely remove the UI from business
logic? "UI references business logic, but business logic should never
reference UI."

For example, a process that cycles thru datarows in a datatable where after
each iteration the UI progress bar needs to be updated (to show a user that
something is going on)? To truely remove the business logic from the UI, I
can't reference a progress bar control as that is UI and hence invalidates
the concept.

You could have an event in your business layer raised whenever a new
datarow is being processed. The UI layer would subscribe to this event and
update its progress bar accordingly. Instead of events, you could also have
a callback function mechanism: the method in your business layer that start
processing the data could take a delegate to a function called whenever a
new datarow is being processed. Same principle as an event really but
depending of how your business layer has been designed, callbacks might fit
in better.

 

[Rob R. Ainscough]

Sure, but that invalidates the separate at a conceptual level, no?

Do you have any links that I could read up on how this is done?

 

[Jared]

In fact, events are a great way to have clean separation between layers
of a system. Your business layer is just raising the events... it
doesn't need to know anything about the code consuming those events.

I'm sorry I don't have time to scan this article for total
relativeness, but it seems like a great place to start:

http://www.ondotnet.com/pub/a/dotnet/2003/06/23/progCsharp3.html

 

[Michael Nemtsev]

Hello Rob,

On your UI get counter of how much data u can get, put this as the max value
of your progressbar, then again read data from BAL.
On BAL u can keep the number of read data for the current session.

You UI and BAL is separated, and BAL has no connection to UI

RA> I understand and implement the concept (as best I can), BUT what I
RA> would like to know -- how is it possible to completely remove the UI
RA> from business logic? "UI references business logic, but business
RA> logic should never reference UI."
RA>
RA> For example, a process that cycles thru datarows in a datatable
RA> where after each iteration the UI progress bar needs to be updated
RA> (to show a user that something is going on)? To truely remove the
RA> business logic from the UI, I can't reference a progress bar control
RA> as that is UI and hence invalidates the concept.
RA>
RA> The only way around this is to NOT provide a very accurate progress
RA> bar or display some animation graphic or use an event timer that
RA> turns on and off when the business logic starts/finishes -- but in
RA> all cases this is not a very accurate representation of the duration
RA> of a particular process. Having looked at some of Microsoft's
RA> products (Windows Defender Beta 2 for example) they don't even
RA> attempt to portray any accuracy -- just an animation that the
RA> process is still running.
RA>
RA> So, I'm curious how you folks resolve this conflict of concept and
RA> retain any accuracy in the state of progress for those long running
RA> tasks?
RA>
RA> Rob.
RA>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Rob R. Ainscough]

Thanks folks, I got the RaiseEvent and withevents working well -- my UI is
now truely separate from the BL.

 

[Joerg Jooss]

Thus wrote Rob,

Sure, but that invalidates the separate at a conceptual level, no?

No. Conceptually, a business object is a server object, and its event listeners
are clients, be it a Windows Forms application, a CUI application, or an
xNunit test class. There's also a couple of interfaces in .NET 2.0 to support
business object events, like System.ComponentModel.INotifyPropertyChanged.

Do you have any links that I could read up on how this is done?

http://msdn.microsoft.com/practices....aspx?pull=/library/en-us/dnpag/html/scag.asp,
especially chapter 2.

Cheers,