UI and BL Interface

[Thomas]

Hi,

I am designing a 3 tier application (UI, BL, and DAL). My UI takes user
input and populates the BL to store into a db. Currently, I am thinking
about design an interface (service/facade) that the UI interfaces between
the BL. I have seen examples that the UI creates and new business object
and stores data into it and passes the business object to the business
process objects. I am going to databind to my business objects so my UI
needs to reference the BL so what is good practice?

Thanks

[liko81@gmail.com]

Re: UI and BL Interface


Thomas wrote:

Hi,
>
I am designing a 3 tier application (UI, BL, and DAL). My UI takes user
input and populates the BL to store into a db. Currently, I am thinking
about design an interface (service/facade) that the UI interfaces between
the BL. I have seen examples that the UI creates and new business object
and stores data into it and passes the business object to the business
process objects. I am going to databind to my business objects so my UI
needs to reference the BL so what is good practice?
>
Thanks

If you don't want the UI to have to know specifically what BL objects
it must deal with, you'll have to design a "middleman" that will handle
that for you. This is why you actually don't hear of "3-tier" as a
methodology much in business; it's referred to as "n-tier". Those tiers
could be the UI, service object and business objects, which you could
break down into controls, which must know different things from the
form, which may or may not know about BL objects, which know about DAO
objects, which know about the database. Web server apps are at least 4
layers, requiring a communications layer like a web service. Most
client-server apps are UI, combined business logic/DAO and database.

To answer your question, a simple, relatively static program with
screen layouts defined at runtime should have no trouble calling
business objects from its controls' events, and that's good practice as
long as the control doesn't have to do much else. The amount to deposit
field should know that it sends its value to the Amount property of a
deposit transaction object. However much more flexibility you need in
designing forms and processing records dictates whether you need an
extra layer or two in your model.

For instance, if you want to dynamically populate a screen with
controls rather than have pre-defined pages/forms/whatever, you'd need
some sort of form builder to go find out what fields you'll need and
put them in the right place. If you don't want your controls to have a
reference to the instance of the business object they must update
(instead only knowing maybe their field name), you'll need an object
handler that will take the field name and value, match the name to an
object and property, and store the value in that property. These extra
layers allow 100% separation of different layers of logic, as well as
increased flexibility of the final product, but it also means extra
memory used, a taller call stack, and a performance hit. It's up to you
to find the balance.