|
 |
application_development thread: Re: Seperating business logic from the UI
Message #1 by keithtoo@h... on Wed, 5 Sep 2001 21:09:02
|
|
Great question!
In my last project, one of the goals was to do just that - separate the
GUI from the business layer. Have you considered COM/DCOM for your app?
That technology makes it relatively easy to segregate GUI and BL and at
the same time allows each to communicate to each other via events.
To use your example of the option button dialog, you would have code
dedicated to the operation of the dlg. If more info from the BL was
required, a COM call can be made which can help the control to decide
what to do. When the control is updated, an event can be fired and any
interested objects can then act on the signal. This keeps your network
traffic to a minimum since the only time you communicate from GUI to
object is when it's absolutely necessary. It also helps to encapsulate
GUI and business layer objects so that only the interfaces are exposed -
not the logic itself.
Breaking your project up into COM components can be quite a challenge,
but well worth the long term rewards.
Hope this helps a bit.
Happy hunting,
Keith
> Hi, I am working on a project converting a 2 tiered application over to
a
> 3 tiered application. One of the many questions I have is what is the
> best way to handle designing the business logic and UI. An example
would
> be, I have an option group with three option buttons. When the user
> selects the third option button, I want to enable a text box and require
> that the user enters in a value. But when they select either the first
or
> second option button, the text box is not required and is disabled.
With
> so many controls on my forms with this type of logic, how can I design
an
> application without congesting up the network?
>
> The plan is to not only convert to a three tiered application, but also
> migrate over to the dot net platform where we want a web front end and a
> windows form front end.
>
> Thanks,
>
> sstewart
Message #2 by Chris.Kaiser@p... on Mon, 10 Sep 2001 13:38:38 -0700
|
|
eah, but to invest that much time into COM when they plan on
migrating to .NET/C# it wouldn't be worth it.
What's your timeframe? If its a large project and you plan on
migrating to .NET anyway, you might want to consider just working
out your .NET strategy and go from there.
As to your gui enabling options... how much information is currently
being transmitted? Is your gui defined dynamically in that a given
screen/dialog's description comes from a database or is it static?
If its completely dynamic, then you could send along a ruleset with
each control's description, such as the option button. Upon activation
of option 1, you would enable/disable a set of controls, as well as
defining validation rules, as in what controls need info, delegating
validation of the control's data to that control.
If you GUI definitions are static, then one option is to use a set
of flags to denote enabling and disabling, and any buttons or check
boxes, or lack of data in a control, would simply modify their appropriate
flags calling an enabing method afterward.
Chris
Message #3 by "Anthony Wilde" <widgetx@h...> on Sun, 30 Sep 2001 16:15:04
|
|
I have developed a number solutions to an n tier design for dealing with
this...
The state of the object(s) are dictated by your biz rules so these can be
defined as a set of rules o.x = 7, o.y > 0 and o.y < 10 etc
The biz object can implement a validation method and return which rule
(failed if any) this can be the input to your GUI.
The GUI needs to implement a "state" depending on the validation rule for
you biz object...
Use the COM event model to raise events changing on the GUI to notify the
biz object of property changes and invoke the validation rule.
If you have a wizard or dialogue then the OK[Next{Finish}] buttons can be
disabled/enabled etc. or use msgbox/focus to inform the use what is wrong
i.e. must enter a value...
By making the rules generic per GUI interface and biz obj Interface the
rules can be tabulated and hence a database solution - XML could be used
to populate the objects rules on demand and cached to reduce network
traffic ... either way the golden rule is build your COM GUI (OCX Contol)
interface to be just that - a pretty picture that displays data and raises
events
Anthony
widgetx.at.hotmail
> Hi, I am working on a project converting a 2 tiered application over to
a
> 3 tiered application. One of the many questions I have is what is the
> best way to handle designing the business logic and UI. An example
would
> be, I have an option group with three option buttons. When the user
> selects the third option button, I want to enable a text box and require
> that the user enters in a value. But when they select either the first
or
> second option button, the text box is not required and is disabled.
With
> so many controls on my forms with this type of logic, how can I design
an
> application without congesting up the network?
>
> The plan is to not only convert to a three tiered application, but also
> migrate over to the dot net platform where we want a web front end and a
> windows form front end.
>
> Thanks,
>
> sstewart
|
|
 |