建立以下要求的最佳方法是什么？ [英] What is the best way to archictect the following requirement.

问题描述

我是设计项目的新手。我不确定以下要求启动项目的最佳方式是什么：



要求是：

a。 GUI发送命令并期望结果。只有在我们从上一次操作中得到结果（通过或失败）后才会发送下一个命令。



b。这些命令被发送到设备。我们需要支持同时向一个或多个设备发送命令。



c。从设备接收的数据需要在GUI中更新，并保存到数据库中。



寻找分层架构。任何帮助将不胜感激。



我的建议是：



a。 GUI将是一层。（不同设备的不同选项卡）

b。设备层将是一个。（单个实例或多个实例将同时支持多个设备）

c。 DB层将是一个。



以下是我需要建议的问题：

a。如何在GUI和设备层之间进行通信？（这里的GUI是一个，但是设备层可以是很多，每个服务器提供相同类型的不同设备）



b。在哪里实现DB接口？...

I am very new to architecting the project. I am not sure what is the best way to start the project with following requirements:

Requirements are:
a. GUI which sends commands and expects the result. Next command will be sent only after we get the result(pass or fail) from the previous operation.

b. These commands are sent to devices. we need to support sending commands to one or more devices simultaneously.

c. The data received from the device need to be updated in the GUI and also saved to the DB.

Looking for the layered architecture. Any help would be appreciated.

My suggestions are:

a. GUI would be one layer.(different tabs for different devices)
b. Device Layer would be one.(single instance or multiple instance will support multiple device simultaneously)
c. DB layer would be one.

Here are my questions for which I need suggestions:
a. how to communicate between GUI and Device Layer?(here GUI is one, but device layer can be many each serving different devices of same kind)

b. Where to instanstiate the DB interface?...

推荐答案

您的建议基本上看起来合理。



该问题还包含UI和设备层之间通信的最合理建议之一：可能是WCF。在这种情况下，最合适的WCF托管将是设备层应用程序中的自托管，它可以是Windows服务，非常适合WCF托管。或者，您可以使用经典远程处理或更低级别，例如TCP套接字（服务端 TcpListener ， TcpClient 在客户端部分）或命名管道。注意，这种类型的传输可以变为WCF 信道，其可以是可替换的/可配置的，以获得更好的灵活性。这个选择将在您的架构的一些更详细的级别。这里最重要的一点是：设备应该是服务，而不是客户。您可以隐藏通用接口背后的设备实现细节。顺便说一句，如果你有不同类型的设备并需要几个不同的接口，那么类似或相关设备组的每个这样的设备都可以作为单独的服务实现。



有关服务的线程问题，请参阅我过去的答案：

一个业余问题套接字编程 [ ^ ]，

来自同一端口号的多个客户端 [ ^ ]，

如何知道AA Tcp连接是否结束 [ ^ ]。



这种设备方法带来了其他好处。您不仅可以将它们与UI，数据层和其他方面隔离开来，还可以将它们放在不同的层中（不要与层混合！）您可以使用一个客户端应用程序调试设备服务，但您的产品客户端应用程序可能不同。您可以将设备层放在不同的平台上。对于WCF，您可能认为它可能会破坏服务合同的好处，这非常方便但是特定于.NET，但是您应该记住CLI和WCF也可用于非Microsoft平台，例如，通过Mono和/或其他第三方平台（例如，CosmOS）。即使您认为现在不需要其他平台，您在架构中提供的额外灵活性也将为您的产品的未来版本打开多平台机会。



第二个问题，实例化DB接口的位置尚不清楚。我不明白你是什么意思。您已经建议了一个单独的数据层，这是非常合理的。您可以在数据层的体系结构及其在应用程序体系结构中的位置上找到很多内容。



从其他方面抽象出来的最重要的部分是UI。这部分是由于一些历史/文化原因。 UI计算是最不稳定的部分，UI设计使用不同的框架并且是最脆弱的。我建议你学习和分析以下架构模式的适用性（ http://en.wikipedia .org / wiki / Architectural_pattern_（computer_science） [ ^ ]）：

MVVM - 模型视图模型，

http://en.wikipedia.org/wiki/Model_View_ViewModel [ ^ ]，



MVC - 模型 - 视图 - 控制器，

http://en.wikipedia.org/wiki/Model-view-controller [ ^ ]），



MVA - 模型 - 视图 - 适配器，
http://en.wikipedia.org/wiki/Model-view-adapter [ ^ ]，



MVP - 模型 - 视图 - 演示者，

http ：//en.wikipedia.org/wiki/Model-view-presenter [ ^ ]。

-SA

Your suggestions basically look reasonable.

The question also contains one of the most reasonable suggestions for communications between UI and device layer: that could be WCF. In this case, the most adequate WCF hosting would be self-hosting in the device-layer application, which could be Windows Service, which is well suitable for WCF hosting. Alternatively, you could use "classical" remoting, or lower level, such as TCP sockets (TcpListener on service side, TcpClient on client part) or named pipes. Note that such kinds of transport can become WCF channels, which can be replaceable/configurable, for better flexibility. This choice would be the in some more detailed level of your architecture. The most important point here is: devices should be services, not clients. You can hide device implementation detail behind the common interface. By the way, if you have different types of devices and need several different interface, each such device of group of similar or related devices could be implemented as a separate service.

For threading issues of the services, see also my past answers:
an amateur question in socket programming[^],
Multple clients from same port Number[^],
How Do I Get To Know If A A Tcp Connection Is Over[^].

Such approach to devices creates other benefits. Not only you isolate them from UI, data layer and other aspects, you can put them in a different tier (not to be mixed up with layers!) You can debug the device services using one client application, but your product client applications could be different. You can place your device layer on different platforms. In case of WCF, you may think that it could defeat the benefit of the service contract, which are very convenient but are specific to .NET, but then you should remember that CLI and WCF are also available on non-Microsoft platform, for example, via Mono and/or other 3rd-party platforms (say, CosmOS). Even if you think that you don't need other platforms now, the extra flexibility you put in the architecture will open the multiplatform opportunities to the future versions of your product.

The second question, "where to instantiate DB interface" is not clear. I cannot understand what do you mean. You already suggested a separate data layer, which is very reasonable. You can find a lot of reading on the architecture of data layers and their place in the application architecture.

The most important part to abstract out from other aspects is UI. This is in part due to some historical/cultural reasons. The UI computing is the least stabilized part, the UI designs use different frameworks and are the most "fragile". I suggest you learn and analyze applicability of the following architectural patterns (http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)[^]):

MVVM — Model View View Model,
http://en.wikipedia.org/wiki/Model_View_ViewModel[^],

MVC — Model-View-Controller,
http://en.wikipedia.org/wiki/Model-view-controller[^]),

MVA — Model-View-Adapter,
http://en.wikipedia.org/wiki/Model–view–adapter[^],

MVP — Model-View-Presenter,
http://en.wikipedia.org/wiki/Model-view-presenter[^].

—SA

这篇关于建立以下要求的最佳方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！