Data Flow in a WPF App
-
Maybe data flow isn't the right question, maybe application organization describes my quandary a little better. Here is what I am trying to do and could stand a bit of help getting there. The app I am creating basically sits between two pieces of equipment and provides data management and communications management between the two. On one side is a piece of equipment that views its world as dealing with a single entity that provides a go no-go result. The other side is a piece of gear that can have of measurements to keep up with. Essentially all this data must be gathered, analyzed and a go no-go be sent. One side expects a TCP/IP server the other is a GPIB bus master. The comms are handled as that was the easy part. Where I am a bit stuck is gluing all this together. The GPIB code and the logic to handle the data is done and runs as a task. The TCP/IP server is done and it runs as a task. I need to add one more piece of logic to handle the decision making plus have a UI that needs to be kept up to date. Right now I have test programs for testing the comms etc. There I have the UI registering event handlers to get notifications of something happening. I use EventWaitHandles to notify the thin interface layers that sit about the comms. All works great! But when I put all this together..............??? I want areas of functionality as loosely coupled as I can for better reuse. In the UNIX world this is simple but in this world, not so much. My inclination is let the MainWindow code behind kick off each task and the tasks expose public methods or permit registering event handlers. But something about this doesn't feel right. In the UNIX world I would have started POSIX threads to handle each functional area and used message queues to facilitate data flow. That way synchronous functionality is grouped and asynchronous is grouped. But the Windows world doesn't seem to operate that way. What I have seen is all the classes/objects are gathered into a single app and there is a lots of "peeking" over the wall to do things which I think tends to make things very tightly coupled. Suggestions? TIA, Doug
-
Maybe data flow isn't the right question, maybe application organization describes my quandary a little better. Here is what I am trying to do and could stand a bit of help getting there. The app I am creating basically sits between two pieces of equipment and provides data management and communications management between the two. On one side is a piece of equipment that views its world as dealing with a single entity that provides a go no-go result. The other side is a piece of gear that can have of measurements to keep up with. Essentially all this data must be gathered, analyzed and a go no-go be sent. One side expects a TCP/IP server the other is a GPIB bus master. The comms are handled as that was the easy part. Where I am a bit stuck is gluing all this together. The GPIB code and the logic to handle the data is done and runs as a task. The TCP/IP server is done and it runs as a task. I need to add one more piece of logic to handle the decision making plus have a UI that needs to be kept up to date. Right now I have test programs for testing the comms etc. There I have the UI registering event handlers to get notifications of something happening. I use EventWaitHandles to notify the thin interface layers that sit about the comms. All works great! But when I put all this together..............??? I want areas of functionality as loosely coupled as I can for better reuse. In the UNIX world this is simple but in this world, not so much. My inclination is let the MainWindow code behind kick off each task and the tasks expose public methods or permit registering event handlers. But something about this doesn't feel right. In the UNIX world I would have started POSIX threads to handle each functional area and used message queues to facilitate data flow. That way synchronous functionality is grouped and asynchronous is grouped. But the Windows world doesn't seem to operate that way. What I have seen is all the classes/objects are gathered into a single app and there is a lots of "peeking" over the wall to do things which I think tends to make things very tightly coupled. Suggestions? TIA, Doug
You can still use a message queue in C# hey! Write your own and test it! ;) There is one in the framework btw! http://msdn.microsoft.com/en-us/library/dd267265.aspx[^]
My programming get away... The Blog... DirectX for WinRT/C# since 2013! Taking over the world since 1371!