串行终端应用程序的设计模式
我作为一名内部串行终端应用程序的开发人员工作。我的目标是编写一个足够灵活的框架，以便我可以使用它来创建三个独立的应用程序：
- 串行终端应用程序（非常类似于超级终端）
- 数据分析应用程序（将根据特定标准对串行数据进行排序和显示）
- 解码应用程序（将处理串行数据并显示数据库中的相关信息）
在将来的某个时候，我想将这三个应用程序合并为一个。然而，这远非优先事项。
我将框架分成三个独立的部分 - GUI（视图接口）、后端（控制器接口）和设置处理程序（ISettingsHandler 接口）。但是，我已经遇到了一些循环依赖问题（ISettingsView 必须移动到与 ISettingsHandler 相同的命名空间），这表明未来会有更多麻烦。
我对每个应用程序的要求如下：
- 串行终端 - GUI 必须能够从串行端口传输数据、显示和修改设置以及发送文件
- 串行分析应用程序 - GUI 必须能够检索传入的串行数据并显示和修改设置
- 解码应用程序 - GUI 必须能够检索传入的串行数据
我是否使其变得比应有的更复杂？我知道我可以用更少的接口完成同样的事情，但我担心这个框架未来使用的灵活性。有没有适合这种场景的设计模式？
编辑：为了澄清，框架的三个“部分”中的每一个都位于不同的命名空间中。
我已经修复了循环依赖关系，但是，我仍然不确定这是否是该应用程序的最佳设计模式。有什么建议吗？
I am working as a single developer on an in house serial terminal application. My goal is to write a framework that is flexible enough that I can use it to create three separate applications:
- Serial terminal application (much like HyperTerminal)
- Data analysis application (will sort and display serial data according to certain criteria)
- Decoding application (will process serial data and display related information from a database)
At some point in the future, I would like to merge these three applications into one. However, this is far from a priority.
I have separated the framework into three separate pieces - the GUI (View interfaces), the backend (Controller interfaces), and the settings handler (ISettingsHandler interface). However, I have already run into some circular dependency problems (ISettingsView had to be moved to the same namespace as ISettingsHandler), indicating more trouble down the road.
My requirements for each application are as follows:
- Serial terminal - GUI must be able to transmit data to and from the serial port, display and modify settings, and send files
- Serial analysis application - GUI must be able to retrieve incoming serial data and display and modify settings
- Decoding application - GUI must be able to retrieve incoming serial data
Have I made this more complex than it should be? I know I could accomplish the same thing with fewer interfaces, but I'm concerned about the flexibility of this framework for future use. Is there a design pattern that fits this scenario?
EDIT: To clarify, each of the three 'pieces' of the framework are in different namespaces.
I have fixed the circular dependency, however, I'm still not sure that this is the best design pattern for this application. Any recommendations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
其中一个设计原则是“好莱坞原则”，其中规定“你不打电话，我们会打电话给你”（来自 Head First 设计模式）
循环依赖是一个常见问题。为了避免这种情况，请遵循这个原则。
不要在较低层引用较高层的接口/类。较高层的类应该使用较低层的接口/类。
例如，ISettingsHandler 应该引用 IController，而不是相反。即使在实现具体类时也尝试遵循该原则。
您的代码将更易于维护。
One of the design principles is "Hollywood principle" which states "You don't call, we will call you" (from Head first design patterns)
Circular dependency is a common problem. To avoid it follow this principle.
Don't refer higher layer interfaces/classes in the lower layer. Higher layer classes should make use of lower layer interfaces/classes.
For example, ISettingsHandler should have a reference to IController and not the other way. Even when you are implementing concrete classes try to follow the principle.
Your code will be more maintainable.
如果遇到循环依赖关系，则需要将共享资源提取到不同的项目中（例如：将所有接口放入 MyProject.Contracts 项目中）。但是，如果遵循正确的分层，就不应该出现这些问题。
If you are running into circular dependencies, you need to extract the shared resources into a different project (Ex: put all Interfaces into MyProject.Contracts project). However, if you follow proper layering, you shouldn't have these issues.
在这里您可以使用基于好莱坞原则的接口依赖注入
Here you can use Interface Dependency Injection which is based opon hollywood principale