General discussion


Best strategy to separate/connect Business Logic and GUI?

By AriB ·
I am designing a desktop application that is basically a control system. As such, the Business Logic is the most important. I would like this to load and run as a system process. I would also like to have a GUI, which can be loaded and closed at will.
The question is, what is the best choice of technology platfor for both, and what IPC/API is best for having the BL communicate with the GUI?
(by the way, the BL must be able to comfortably use ActiveX).

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

a new Windows here?

by dawgit In reply to Best strategy to separate ...

since you'll be useing MicroSoft, (for the active X) are you trying to re-invent the wheel? (Windows)

Collapse -

Depends on what the GUI

by Tony Hopkinson In reply to Best strategy to separate ...

needs to do.

Which way you go depends on whether the business logic is executing when no GUI is connected to it.

Is the business logic service that performs tasks other than those requested by the GUI. Say recording data in a DB/file from a sensor.

Or is it a set of abstracted rules, say calculations for a type of model.
Which communication method you use between the GUI and the service depends on the volume of information being transferred, the frequency of communications and how multiuser/ multi threaded it needs to be .

For instance you wouldn't want to use a common disk file to communicate if 85 people could be twiddling with it at the same time. Well you could but it would be a lot of work in terms of access and transisoltion and woefully inefficient at high frequency.
There you would probably be better off using a DBMS as it comes with those wheels in place.

Also I don't understand what you mean by use activeX, do you mean it must be a COM server or it needs activeX functionality to do it's job with some other activeX compliant code ?

Collapse -

What the GUI does...

by AriB In reply to Depends on what the GUI

Hi Tony, thanks for your reply.
As for the GUI, well actually I will get to that in a moment.
The Business Logic (BL) is actually a monitoring system that connects sensors with some devices that have to be activated. The devices are conected using ActiveX (MFC COM) "drivers" (Why ActiveX is a good question, the reason really being that is was needed for some prototyping environment). So, in routine operations, there is no need for GUI at all. The BL should just load as a service and run.
So what is the GUI for? Well, the GUI is used for a few things:
1) Montoring the system (just seeing what's going on).
2) Configuration (on setup or maintanance)
3) Pulling reports from the database
The intensity of communications between the BL and the GUI is not taht much. Apart from reports and maintenance, the GUI as I said is mainly for status monitoring (of the connected devices) and this is "info only".
What the BL is executing when no GUI is connected (well, when it is connected also) is to monitor the sensors and then if some actiona is required (based on some conditions), active a device. This also is not very intensive.
In truth I guess the entire thing could be put in a single application, but the idea of having a service is mainy a requirement because of not wanting to have the system depend on a user for logging in (which would then run a startup task). Power outages (longer than UPS...) are common.
I hope these anser some of your questions...
Your comments are much appreciated!

Collapse -

Now we are cooking

by Tony Hopkinson In reply to What the GUI does...

I agree the sensor control and recording should be in a service.
The service communicates to the sensors through activeX. The GUI needs to know nothing about that.

My initial thought seeing as this is not that intensive is you use a table in the database for communicating with the GUI.

The service reads it's configuration from the db and control signals, may be stop/start/restart/ config change.

The gui reads and writes from the config and control tables and does the reports.
Not only complete separation, you have the potential to control the service from any DB-aware application.

If you don't like the db idea, you could use the registry with a polling method in the service, or even couple of files. Event based you are at RPC calls (uggh) or windows messages.

GUI, writes to config and control service reads.
service writes to status and GUI reads

The other thing you need to cope with is there is nothing to stop anyone running the GUI more than once, so you'll need some way of either using a token for control so, only one GUI at at time can do it, or potentially dealing with conflicting commands from several GUIS.

The token idea is nice but you need to deal with it being left set erroneously locking out all subsequent GUIS. If you use a DB, you could easily queue a set of commands for the service, or simply get the GUI to put a lock on the record and then execute or or an inactivity timer drops it.

A few ideas anyway.

Keep the actions the GUI can take as atomic as possible if you go for multiple GUIs, that way there's less chance of a livelock.

Hmmm also if you use the DB for command and control, you can run the GUI from any machine that can access the database, which might be useful.


Collapse -

More cooking ;-)

by AriB In reply to Now we are cooking

Hi and thanks, all good thoughts and suggestions. I have a few questions:

1. When you refer to using a DB, would this be the same idea as using a a Mapped File? (and if so, what is the difference?)

2. If DB or File, I assume this would also be the way to maintain state information as well as pass status changes (but then you have to poll it I assume).

3. I am somewhat in favor of an event-driven architecture. You refer to RPCs. Is COM not a good way to go also?

4. The issue of preventing multiple GUIs from accessing the BL is a good one. Ideally, calling the same GUI process (i.e. running the program) would either open it (if it is closed), or just do nothing (or show it if say minimized) if already running. How would this be acheived?

5. Last but not least, what language would you suggest that the BL be written in?

Many thanks!

Collapse -


by Tony Hopkinson In reply to More cooking ;-)

1) the advantage of using a db over a mapped file, is that all locking, contention issues have already been solved. It already has those mechanisms. You could go to mapped file, but the you have to write all the threading code.

For instance reading control information in mid write.

2) You can do state as well and yes you will be polling.

3) Event architecture, You can certainly go for this though unless you need an 'immediate' response to a signal, I fail to see the need for the extra level of complexity. COM by itself will not give you an event model, you still need some way of generating an event.

Now you could get the service to generate a COM object on request for the GUI and then pass information through it which would cause an event to be raised in the service or the GUI, but you could do that with a mere windows message.

4) The standard way of doing single instance, is to do a FindWindow (windows API) . If it's there, send a restore windows message to it (FindWindow returns the handle) and close or continues executing. That gets rid of all the problems with multple commands to the service, but doing that I'd be seriously tempted to do reporting from a separate application.

5) VB could do it at a push, C++ or perhaps even C#.

Related Discussions

Related Forums