Separating business and presentation logic in different threads
-
Hi fellow CP-ers. I worked with monstrous legacy C/C++ code where the GUI and business logic components are executed in the same thread. It worked fine, but the GUI is similar to Win 3.1 style: ugly clunky and yucky (sorry for hardcore 3.1-ers!). Since then we upgraded our system with new GUI tools and processors. We decided to take this opportunity to untangle the system. We put all the biz logic in one thread (this hosts multiple apps, drawing or non-drawing), and all related GUI items (rendering loop, animations, and all its support classes) on the other thread. IMO, this is very beneficial since for example the button may animate fade in or out, etc, while the biz logic thread can still host other non-drawing applications. Note that we will try to do as much as we can locally in rendering thread if it doesn't involve biz logic (ex: highlights, international strings, etc). If it requires data, it will post to biz logic thread and retrieve it. So this new guy came in and decided to put all the GUI classes back to the business logic thread. Rendering is still done on other thread, but now for every single little graphics primitives (think set colors, move obj to x,y, set transparency, etc) we need to send out a message. His reasoning is that it's too clumsy to post handler messages to other thread, he prefers call back, and he said it's common for most GUI frameworks to have this synchronous behavior. Can someone help me explain why the synchronicity of button handler is so important? Am I missing something? Don't we already have similar model of biz logic / presentation separation in present day web technology? (i.e. Fancy flash animations in your web browser sending/fetching data from the server, or AJAX heavily used by Google apps?)
-
Hi fellow CP-ers. I worked with monstrous legacy C/C++ code where the GUI and business logic components are executed in the same thread. It worked fine, but the GUI is similar to Win 3.1 style: ugly clunky and yucky (sorry for hardcore 3.1-ers!). Since then we upgraded our system with new GUI tools and processors. We decided to take this opportunity to untangle the system. We put all the biz logic in one thread (this hosts multiple apps, drawing or non-drawing), and all related GUI items (rendering loop, animations, and all its support classes) on the other thread. IMO, this is very beneficial since for example the button may animate fade in or out, etc, while the biz logic thread can still host other non-drawing applications. Note that we will try to do as much as we can locally in rendering thread if it doesn't involve biz logic (ex: highlights, international strings, etc). If it requires data, it will post to biz logic thread and retrieve it. So this new guy came in and decided to put all the GUI classes back to the business logic thread. Rendering is still done on other thread, but now for every single little graphics primitives (think set colors, move obj to x,y, set transparency, etc) we need to send out a message. His reasoning is that it's too clumsy to post handler messages to other thread, he prefers call back, and he said it's common for most GUI frameworks to have this synchronous behavior. Can someone help me explain why the synchronicity of button handler is so important? Am I missing something? Don't we already have similar model of biz logic / presentation separation in present day web technology? (i.e. Fancy flash animations in your web browser sending/fetching data from the server, or AJAX heavily used by Google apps?)
The are two principles mixed together here: 1) Splitting business logic and GUI logic - This is good as it allows one to write unit-tests that can test the business-logic without needing to test using the GUI. 2) Using worker-threads to perform long running operations - This gives a good GUI experience, as the GUI remains responsive even when doing heavy processing. Multi-threaded programming increases the complexity of the code. So it should only be introduced where it actually provides a performance boost. I have no problem in understanding why your new developer wants to make synchronous requests as it is so much simpler. I have no clue about your customer base, or the type of application you are building. But the tendency is that we work towards client/server based applications, where the client is launched through a web-browser (ASP.NET / Silverlight) and the Server is available from the Internet (Easy deployment, Centralized hosting and backup). In this scenario then the splitting of GUI and business logic should come natural.
modified on Monday, December 14, 2009 5:09 PM