CODEWITHSUNDEEP
user-interfacearchitectureipc
PTBG
PTBG

Reputation: 595

What is the proper way to make a GUI

I am working on a series of different software products. They are quite old, so we're in the process of re-factoring/improving them. My co-worker had the idea of abstracting the GUI and having it run in its own process and communicate with the logical portion of the program via sockets. This will allow us to use the same GUI components with all of the different applications (keeping the same LAF). So my question is: Is this a valid practice for creating a GUI? Would I be better off keeping the GUI tied in with the rest of the program? what are the pros and cons of the different methods, and are there any other methods for implementing GUIs?

Thanks

Upvotes: 1

Views: 322

Answers (3)

jgauffin
jgauffin

Reputation: 101150

Depends on the type of application.

Desktop applications

It makes sense if the server can be run on a dedicated server. It does not make sense if both the server and the GUI are going to be installed on each desktop (for most applications). Then use different projects/dlls to separate the UI/Business logic.

Web applications

Yes. Many web applications have separate service layer an uses SOAP for communication between the GUI and the service layer.

Sockets

Using vanilla sockets is seldom a good choice today. Why waste energy/time of building your own protocol and implementation when there are several excellent IPC frameworks available.

Update in response to comment

Divide and conquer. Break down the UI into as small components as possible to make them reusable. Put those components into a separate project/dll. A sample component can be a UserTable which presents a list of all users (taking a dependency of the interface IUserService).

Don't try to reuse the entire UI layer since it's doomed to fail. The reason is that if you try to make a UI which should be configurable and generic you'll probably end up spending more time on that than what it would have taken to build a specific UI using reusable components. And in the end, you need to add small "hacks" to make minor changes to the generic UI layer to suit each application. It WILL end up in a emss.

Instead reuse the above mentioned components to build a specific UI for each application.

Upvotes: 1

mikalai
mikalai

Reputation: 1736

With service and presentation layers properly designed that should be perfectly all right. To summarize pros and cons in my opinion:

Pros:

  1. UI not bound physically to logic, so logic layers can be remote (or even standalone BL server for several clients). Let's call is "Business logic location independence".
  2. Possibility to create different versions of GUI (and not only graphical - it would be possible to expose BL as a service, for example as a feed or reporting endpoint), "GUI platform independence", and also SOA approach.
  3. Possibility to add a proxy between BL and GUI - for security and caching purpose. Or load balancer in front of application farm. Or an adapter to support "old" clients after significant BL changes. ("Resiliency and fail-safety"?)
  4. Deployment could be easier to some extent (fixing bugs in UI wouldn't affect BL layer - just a consequence of binary module independence)
  5. Ability to add "offline mode" to GUI.

Cons:

  1. You're adding one more connection link, which could be yet another fail point, and some effort should be spent for testing that.
  2. Increase of data traffic between GUI and BL, and probably more serialization work.
  3. Need to track communication protocol changes and proper protocol versions maintenance.
  4. (Negative side of proxy ability) Possibility of man-in-the-middle attack between GUI and BL.

Upvotes: 1

Bryan Oakley
Bryan Oakley

Reputation: 386210

Yes, it's a perfectly valid way to write a GUI program. This is roughly how web apps work -- the UI (browser) communicates to the business logic server (web server) over a socket.

It's a little bit unusual for a desktop application, but it's quite acceptable. The beauty of this solution is that it lets you write multiple rich clients for different platforms (think mobile app, windows app, browser-based app, etc.)

All you need to do is define the API that a GUI will need to talk to the back end. For example, it will need a way to get objects and save objects, and to receive notifications from the back end that the UI needs updating.

Upvotes: 1

Related Questions