UI and Application relationship

Question

Hi All,

I've read a lot of articles about the UI ,buisness logic ,WCF ,IoC, but still, one thing is missing from my mind. I build a winforms application and a console app. the Console App is the brain. Now, in all the client-server architecture the client "know" the server , send him request and get the answer. My qestion is as follow:

1) How can the console application display a message to the user if he doens't know the existence of the UI? Should the UI check and pool for the messages every x msec? is it a good approach?

2) what in the case that the UI forms should display a ticker price ,e.g stock price which changes all the time ? should it request the ticker price from the console app every 200msec? or register a callback function in the console application so the console application can call it? However, doesn't it make the UI into a server now?

3) What happen in case that I want to add a terminal capbilities to my application (e.g telnet cli ), how should I design it ? the telnet server as a client and my console application as the server? is there a design that can help me to achieve that? CAB? I asked a lot of people and it seem that nobody is using it... is that so?

Thanks, Eyal

Answer 1

Why don't you create the "brain" as a library? Both a WinForms interface and a console app are user interfaces and should be seperated from the logic. This allows easier access to functions and you could also subscribe to events.

Answer 2

Your program should be designed in such a way that you can replace one UI with another. The program should be able to have the logic function independently from the interface that the user sees. Take a look at the MVC and Observer patterns.

One good measure of your program is through the interfaces that are made available to the user [API calls, console based GUI, console based interface, net interface, web] I'm not implying that you should refocus the intention of the application to be on making it very flexible with the interface. I'm suggesting that your interface should have nothing to do with the logic and datastore of your application.

Stock ticker: Have an oberserver pattern that broadcasts a new event every 200ms, or on changes. The ticker view would be a subscriber of these events.

Answer 3

You should avoid the architecture you are contemplating. Getting two separate processes to work together is complicated. The operating system puts up a big wall between processes to make sure that one misbehaving process cannot destabilize another. Processes each have their own view of memory, Windows (and .NET especially) makes it very difficult for processes to share memory.

You'd have to establish a communication channel between processes to get them to work together. A pipe or a socket is the usual choice, the mental model here is of machines talking to each other over a network. This can be very awkward, you'd have all of the disadvantages of a web application, none of the advantages of a WinForms client or console mode app. It is also very unreliable, failure of one process is hard to diagnose, report and recover from by the other app. I'm sure you've seen what can go wrong from using your Internet browser.

You can get what you want from one application. The System.Threading.Thread class gives you the moral equivalent of your console mode app. Getting the UI to display messages from the brain thread is fairly simple with the BackgroundWorker class or the Control.Begin/Invoke() method. Only "fairly" btw, getting thread interop right is still an effort.

There are two ways to get the stock ticker update implemented. The push vs the pull approach. The push approach is letting the background thread actively notify the UI thread that an update is available. BackgroundWorker.ReportProgress or Control.Begin/Invoke to do that. At 200 msec updates, this is not a problem.

At rates like this, the pull model will work just as well. You'd use a Timer in the UI to get a method to run periodically. It could read the value from a shared property in the timer's Tick method. You'll need to use the lock statement in both the background thread and the Tick method to ensure that the value cannot change just as the UI thread is reading the value.

You should favor the pull model when the value can change very rapidly, pushing at a rate that will bring the UI thread to its knees when the time needed to update the UI is longer than the period between updates from the background thread. The UI thread will fall behind and doesn't get around to its normal duties. A frozen UI is the diagnostic, OOM is the end result. 200 msec should not be a problem unless you get very fancy or sloppy with your UI updates, push should work.

I'll have to join the league of friends you consulted about telnet servers. Not sure what problem they solve, they are the 1990 equivalent of a web server when everybody was using a green screen terminal to talk to a computer. It perhaps applies to the need of connecting a separate console mode app to a UI app. You wouldn't use telnet to do that, a socket is a generic channel. .NET Remoting or, better, WCF is the layer that sits on top of that channel to avoid having to deal with the complications of squeezing data or method parameters through a pipe of bytes. Pursue that if you are completely boxed into a multi-process solution already. You shouldn't be for a stock ticker app, nobody cares which way they tick if there isn't anybody there to look at them. Falling tree in the forest, perhaps.