Wrox Home  
Search P2P Archive for: Go

  Return to Index  

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

  Return to Index