0

我已经阅读了很多关于 UI、业务逻辑、WCF、IoC 的文章，但是我仍然缺少一件事。我构建了一个 winforms 应用程序和一个控制台应用程序。控制台应用程序是大脑。现在，在所有客户端-服务器架构中，客户端“了解”服务器，向他发送请求并获得答案。我的问题如下：

1) 如果用户不知道 UI 的存在，控制台应用程序如何向用户显示消息？UI 是否应该每 x 毫秒检查和汇集消息？这是一个好方法吗？

2) 如果 UI 表单应该显示股票价格，例如一直在变化的股票价格，该怎么办？它应该每 200 毫秒从控制台应用程序请求一次股票价格吗？或者在控制台应用程序中注册一个回调函数以便控制台应用程序可以调用它？但是，现在不是把 UI 变成了服务器吗？

3）如果我想为我的应用程序添加终端功能（例如 telnet cli ）会发生什么，我应该如何设计它？telnet 服务器作为客户端，我的控制台应用程序作为服务器？有没有可以帮助我实现这一目标的设计？出租车？我问了很多人，似乎没有人使用它……是这样吗？

谢谢， 埃亚尔

4

3 回答 3

2

您的程序应该以这样一种方式设计，即您可以用另一个 UI 替换一个 UI。程序应该能够具有独立于用户看到的界面的逻辑功能。看看MVC和观察者模式。

您的程序的一个很好的衡量标准是通过向用户提供的接口 [API 调用、基于控制台的 GUI、基于控制台的接口、网络接口、Web] 我并不是说您应该重新关注应用程序的意图使界面变得非常灵活。我建议您的界面应该与应用程序的逻辑和数据存储无关。

股票行情：有一个观察者模式，每 200 毫秒广播一个新事件，或者在变化时广播一个新事件。股票代码视图将是这些事件的订阅者。

于 2009-12-19T20:57:37.107 回答
1

为什么不将“大脑”创建为图书馆？WinForms 界面和控制台应用程序都是用户界面，应该与逻辑分开。这样可以更轻松地访问功能，您还可以订阅事件。

于 2009-12-19T20:57:21.447 回答
1

你应该避免你正在考虑的架构。让两个独立的进程一起工作很复杂。操作系统在进程之间竖起了一堵大墙，以确保一个行为不端的进程不会破坏另一个进程的稳定性。每个进程都有自己的内存视图，Windows（尤其是 .NET）使进程很难共享内存。

您必须在进程之间建立通信通道才能让它们一起工作。管道或套接字是通常的选择，这里的心智模型是机器通过网络相互通信。这可能很尴尬，您将拥有 Web 应用程序的所有缺点，而没有 WinForms 客户端或控制台模式应用程序的优点。它也非常不可靠，一个进程的故障很难被另一个应用程序诊断、报告和恢复。我相信您已经看到使用 Internet 浏览器可能出现的问题。

你可以从一个应用程序中得到你想要的。System.Threading.Thread 类为您提供控制台模式应用程序的道德等价物。使用 BackgroundWorker 类或 Control.Begin/Invoke() 方法让 UI 显示来自大脑线程的消息相当简单。顺便说一句，只是“相当”，让线程互操作正确仍然是一项努力。

有两种方法可以实现股票代码更新。推与拉的方法。推送方法是让后台线程主动通知 UI 线程有更新可用。BackgroundWorker.ReportProgress 或 Control.Begin/Invoke 来做到这一点。在 200 毫秒更新时，这不是问题。

在这样的速率下，拉动模型也可以正常工作。您将在 UI 中使用 Timer 来获取定期运行的方法。它可以从计时器的 Tick 方法中的共享属性中读取值。您需要在后台线程和 Tick 方法中使用 lock 语句，以确保值不会在 UI 线程正在读取值时更改。

当值可以非常迅速地变化时，您应该支持拉模型，当更新 UI 所需的时间长于后台线程更新之间的时间间隔时，推的速率会使 UI 线程屈服。UI 线程将落后，无法履行其正常职责。冻结的 UI 是诊断，OOM 是最终结果。除非您对 UI 更新非常花哨或草率，否则 200 毫秒应该不是问题，推送应该可以工作。

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.

于 2009-12-19T23:02:46.063 回答