我的公司目前正在使用C#创建一个大型多层软件包。我们已经对结构采用了SOA方法,我想知道是否有人对如何使具有编程知识的用户可以扩展它有任何建议。
这将涉及双重过程:生产系统的管理员批准允许使用特定的插件,以及实际的插件架构本身。
我们希望允许用户编写脚本来执行常见任务,修改用户界面的布局(用WPF编写)并添加新功能(即允许制表列表数据)。有没有人对如何实现这一点有任何建议,或者知道在哪里可以获得知识来做这种事情?
我认为这对于发布具有限制性发布许可证的软件开源来说是完美的角落,但是,我并不热衷于允许竞争对象访问我们的源代码。
感谢。
编辑:我想澄清一下,解释为什么我选择了我做的答案。我指的是公司外部的生产管理员(即客户端),并且让他们以更容易的方式自动化/编写脚本,而不需要他们完全了解c#(他们主要是编程有限的最终用户)经验) - 我更多地考虑DSL。这可能是一个遥不可及的目标,而Managed Extensibility Framework似乎提供了迄今为止最好的折衷方案。答案 0 :(得分:8)
只需使用界面。定义每个插件必须实现的IPlugin,并使用定义良好的消息传递层允许插件在主程序中进行更改。您可能希望查看像Mediaportal或Meedios这样严重依赖用户插件的程序。
答案 1 :(得分:6)
正如史蒂夫所说,使用接口可能是要走的路。您需要设计您希望客户端使用的接口集,设计插件的入口点以及插件通信模型。除了Steve的建议,您可能还想看一下Eclipse项目。他们有一个非常明确的插件架构,即使用java编写,也值得一看。
另一种方法可能是设计可用于脚本语言的API。都 IronPython和Boo是动态脚本语言,可以很好地与C#配合使用。通过这种方法,您的客户可以编写脚本来与您的应用程序进行交互并扩展您与完整的插件系统相比,这种方法更像是轻量级解决方案。
答案 2 :(得分:4)
我会看一下微软的 MEF 计划。它是一个框架,可以让您为应用程序添加可扩展性。它现在处于测试阶段,但应该是.Net 4.0的一部分。
Microsoft共享源代码,因此您可以查看它的实现方式并与之进行交互。因此,基本上您的可扩展性框架将供所有人查看,但它不会强制您发布应用程序代码或插件代码。
答案 3 :(得分:2)
开源不需要任何形式或形式来使产品可扩展。
答案 4 :(得分:1)
我同意在这种情况下开源是一个可怕的想法。当您说生产管理员的批准时 - 您公司内部的管理员还是外部管理员?
就个人而言,我会考虑通过继承允许可扩展性(允许第三方将代码子类化而不给它们提供源代码)以及非常谨慎指定的访问修饰符。
答案 5 :(得分:1)
Microsoft已经做到了这一点,从而产生了Reporting Services,它具有您提到的每个属性:用户定义的布局,脚本,图表,可自定义的UI。这包括可下载的IDE。不提供或不需要访问源代码,但它充满了可扩展性钩子。缺少源代码会抑制紧密耦合并促进SOA思考。
答案 6 :(得分:0)
我们目前处于类似情况。我们确定了人们可能希望在数据级别上创建实时连接的不同场景。在这种情况下,他们可以访问sinle webservice来请求和导入数据。
在某些时候,他们可能想要一个自定义用户界面(在我们的案例中是Silverlight 2)。对于这种情况,我们可以提供一个基类,让他们在中央存储库中注册该模块。然后它以统一的方式集成到我们的应用程序中,包括安全性,形式和行为以及与服务的交互。