串行终端应用程序的设计模式

我作为内部串行终端应用程序的单个开发人员工作。我的目标是编写一个框架，具有足够的灵活性，我可以用它来创建三个独立的应用程序：串行终端应用程序的设计模式

串行终端应用程序（很像超级终端）
数据分析中的应用（将整理并显示根据串行数据一定的标准）
解码应用（将处理串行数据，并从数据库中显示相关信息）

在未来的某个时刻，我想这三个应用程序合并为一个。但是，这远非优先事项。我已经将框架分成三个独立的部分 - GUI（视图接口），后端（控制器接口）和设置处理程序（ISettingsHandler接口）。但是，我已经遇到了一些循环依赖问题（ISettingsView必须移动到与ISettingsHandler相同的命名空间），表明了更多的麻烦。是

我的针对每个应用的要求如下：

串行终端 - GUI必须能够将数据传输到和从串行端口，显示和修改设置，和发送文件
串行分析应用 - 界面必须能够检索收到的串行数据，并显示和修改设置
解码应用 - GUI必须能够检索输入的串行数据

我是否比这应该是更复杂？我知道我可以用更少的接口完成同样的事情，但我担心这个框架的灵活性，以备将来使用。有没有适合这种情况的设计模式？

Current pattern diagram

编辑：为了澄清，每个框架的三个“片”的是在不同的命名空间。

我已经修复了循环依赖，但是，我仍然不确定这是否是此应用程序的最佳设计模式。任何建议？

来源

2011-02-01 CWMan

命名空间是逻辑分隔符和一种组织类的方法。你如何组织他们取决于你。如果它们不相关，我不会将它们放入同一个命名空间。 – 2011-02-01 17:12:53

之一的设计原则是“好莱坞原则”，规定“你不打电话，我们会打电话给你”（从头部首先设计模式）

循环依赖是一个常见的问题。为了避免它遵循这个原则。

请勿在较低层中引用较高层接口/类。高层类应该使用低层接口/类。

例如，ISettingsHandler应该引用IController而不是其他方式。即使你正在实施具体的课程，也要遵循这个原则。

您的代码将更易于维护。

来源

2011-02-03 05:45:03

如果您正在运行循环依赖项，则需要将共享资源提取到不同的项目中（例如：将所有接口放入MyProject.Contracts项目中）。然而，如果你遵循适当的分层，你不应该有这些问题。

来源

2011-02-01 16:43:14

我应该将所有接口放在同一个命名空间吗？我的印象是，它们应该放在相同的命名空间中，因为从它们派生的类将被放置。 – CWMan 2011-02-01 16:59:32

接口与类无关。接口是任何人都可以实现的契约，所以它们不需要在同一个名称空间中。如果你有全部三层引用一个接口，你需要将它提取到一个没有引用任何其他项目的共享项目中。这就是你解决循环问题的方法。你如何组织他们取决于你。 – 2011-02-01 17:03:04

在这里，您可以使用基于opon好莱坞principale的接口依赖注入

来源

2011-06-09 11:29:56 Kamahire

串行终端应用程序的设计模式

回答

相关问题