在工业软件体系结构中使用插件方法的好处

Question

我正在尝试设计一个应用程序，这是在.NET C#堆栈上非常通用的东西。

它应该是一个桌面应用程序，旨在控制工业设备和执行测量和测试，但它计划以后能够切换到不同的UI处理不同的

我正在尝试一种相当通用的方法：

• UI不可知论者: Webpages / Winforms / WPF / GTK# / Whathever等使用裸对象，以避免大量锅炉板用户界面代码的麻烦。
• 数据库无关的存储数据(ADO.NET & EF可以处理这个问题)
• 远程控制和监视(这确实很棘手，但我想使用WCF，我应该能够在远程客户端上运行服务来实现远程访问)
• 用户管理
• 外部工业资源(设备)
• 日志记录和错误报告
• 报告和数据出口
• 许可

应用程序的业务层分为三个主要部分，并利用上面描述的其他部分：

• 版本:使用可用的工业资源定义一组带有条件(用户交互、测试期间获取的结果)的测试(流程图)。
• 操作:使用用户交互(如果在上一步中定义的话)执行上面定义的测试。
• 分析:处理与编辑部分给出的测试定义相对应的数据(DB)，并提供一些统计计算:数据挖掘特征(聚类、异常检测等)。以及报告功能(也可以定义为在操作的不同时刻自动生成)。

我的问题是，我想要一个模块化的方法，我想知道这在我的情况下是否真的是可取的。这一方法是合理的，但同时似乎提供了许多问题。

理论上，这意味着您可以独立地测试您的模块，但是在大多数情况下，即使您可以模拟测试所需的输入/输出，实际情况仍然是，它需要其他依赖项才能运行，这对我来说是这种方法的真正底线。事实上，您可以加载和卸载一些对我来说只适用于几种情况，但没有那么多。

例如，用户管理正在使用数据库模块，该模块可能还会使用另一个加密模块，等等。

后来远程控制和监控最终也会用到那个所以..。我的观点是，在这里似乎很难让模块完全独立。

插件/模块化方法对于外部工业资源来说就像一种魅力，而这些设备必须实现与系统兼容的特定接口。

但是对于其他的问题，我真的很怀疑它是否值得使用MEF或任何其他插件/扩展框架。

你认为如何？模块化方法真的适用于我的情况下的一切吗？或者仅仅有几个特性就可以利用它。

Answer 1

我们正在用不同的方法在同一体系结构上工作。目前我们使用EF的插件方法，因为当我们谈论许可和报告时，应该是基于客户的需求或需求，例如，目前一些客户需要一些基于许可的应用程序的基本特性，而有些客户需要更多的特性和自定义基础报告，所以每次您不需要构建整个项目、更新或上传服务器时。即插即用架构师是好的，当一些现有的客户需要一些新的功能，以便您可以开发，上传和插件，所以没有必要为每个客户设置，我希望这将有助于您。谢谢