无需开源的可扩展性
我的公司目前正在用 C# 创建一个大型多层软件包。 我们对结构采用了 SOA 方法，我想知道是否有人对如何使其可由具有编程知识的用户进行扩展有任何建议。
这将涉及两个过程：生产系统管理员批准允许使用特定插件，以及实际的插件架构本身。
我们希望允许用户编写脚本来执行常见任务、修改用户界面的布局（用 WPF 编写）并添加新功能（即允许将表格数据制成图表）。 有谁对如何实现这一点有任何建议，或者知道从哪里可以获得做这类事情的知识？
我认为这将是发布具有限制性分发许可证的开源软件的完美案例，但是，我并不热衷于允许竞争对手访问我们的源代码。
谢谢。
编辑：我想我只是澄清一下为什么我选择了我所做的答案。 我指的是我公司外部的生产管理员（即客户端），并为他们提供某种方式以更简单的方式自动化/编写脚本，而不要求他们完全了解 C#（他们大多是编程能力有限的最终用户）经验）——我更多地考虑的是 DSL。 这可能是一个遥不可及的目标，而托管可扩展性框架似乎提供了迄今为止最好的折衷方案。
My company is currently in the process of creating a large multi-tier software package in C#. We have taken a SOA approach to the structure and I was wondering whether anyone has any advice as to how to make it extensible by users with programming knowledge.
This would involve a two-fold process: approval by the administrator of a production system to allow a specific plugin to be used, and also the actual plugin architecture itself.
We want to allow the users to write scripts to perform common tasks, modify the layout of the user interface (written in WPF) and add new functionality (ie. allowing charting of tabulated data). Does anyone have any suggestions of how to implement this, or know where one might obtain the knowledge to do this kind of thing?
I was thinking this would be the perfect corner-case for releasing the software open-source with a restrictive license on distribution, however, I'm not keen on allowing the competition access to our source code.
Thanks.
EDIT: Thought I'd just clarify to explain why I chose the answer I did. I was referring to production administrators external to my company (ie. the client), and giving them someway to automate/script things in an easier manner without requiring them to have a full knowledge of c# (they are mostly end-users with limited programming experience) - I was thinking more of a DSL. This may be an out of reach goal and the Managed Extensibility Framework seems to offer the best compromise so far.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
只需使用接口即可。 定义每个插件都必须实现的 IPlugin，并使用定义良好的消息传递层来允许插件在主程序中进行更改。 您可能想看看像 Mediaportal 或 Meedios 这样的程序，它们严重依赖于用户插件。
Just use interfaces. Define an IPlugin that every plugin must implement, and use a well defined messaging layer to allow the plugin to make changes in the main program. You may want to look at a program like Mediaportal or Meedios which heavily depend on user plugins.
正如史蒂夫所提到的，使用界面可能是正确的选择。 您需要设计希望客户使用的一组接口，设计插件的入口点以及插件通信模型。 除了 Steve 的建议之外，您可能还想看看 Eclipse 项目。 他们有一个非常明确的插件架构，尽管它是用 java 编写的，但可能值得一看。
另一种方法可能是设计可用于脚本语言的 API。 两个都
IronPython 和 Boo 是与 C# 配合良好的动态脚本语言。 通过这种方法，您的客户可以编写脚本来与您的应用程序交互并扩展您的应用程序。 与完整的插件系统相比，这种方法更像是一种轻量级解决方案。
As mentioned by Steve, using interfaces is probably the way to go. You would need to design the set of interfaces that you would want your clients to use, design entry points for the plugins as well as a plugin communication model. Along with the suggestions by Steve, you might also want to take a look at the Eclipse project. They have a very well defined plugin architecture and even though its written in java, it may be worth taking a look at.
Another approach might be to design an API available to a scripting language. Both
IronPythonand Boo are dynamic scripting languages that work well with C#. With this approach, your clients could write scripts to interact with and extend your application. This approach is a bit more of a lightweight solution compared to a full plugin system.
我会看一下 Microsoft 的 MEF 计划。 它是一个允许您为应用程序添加可扩展性的框架。 它现在处于测试阶段，但应该是 .Net 4.0 的一部分。
Microsoft 共享源代码，因此您可以查看它的实现方式以及与其交互的方式。 因此，基本上您的可扩展性框架将开放给所有人查看，但它不会强迫您发布应用程序代码或插件代码。
I would take a look at the MEF initiative from Microsoft. It's a framework that lets you add extensibility to your applications. It's in beta now, but should be part of .Net 4.0.
Microsoft shares the source, so you can look how it's implemented and interface with it. So basically your extensibility framework will be open for everyone to look at but it won't force you to publish your application code or the plug-ins code.
开源并不需要以任何方式或形式来使产品具有可扩展性。
Open source is not necessary in any way shape or form to make a product extensible.
我同意在这种情况下开源是一个可怕的想法。 当您说生产管理员批准时，该管理员是您公司内部的还是外部的？
就我个人而言，我会考虑通过继承来允许扩展性（允许第三方在不提供源代码的情况下对您的代码进行子类化）和非常仔细地指定访问修饰符。
I agree that open source is a scary idea in this situation. When you say approval by a production administrator - is that administrator within your company, or external?
Personally, I would look at allowing extensibility through inheritance (allowing third parties to subclass your code without giving them the source) and very carefully specified access modifiers.
Microsoft 已经做到了这一点，从而产生了 Reporting Services，它具有您提到的所有属性：用户定义的布局、脚本能力、图表、可定制的 UI。 其中包括一个可下载的 IDE。 不提供或不需要对源代码的访问，但它绝对充满了可扩展性挂钩。 源代码的缺乏抑制了紧密耦合并促进了 SOA 思维。
Microsoft already did exactly this, resulting in Reporting Services, which has every attribute you mention: user defined layout, scriptability, charting, customisable UI. This includes a downloadable IDE. No access to source code is provided or required, yet it's absolutely littered with extensibility hooks. The absence of source code inhibits close-coupling and promotes SOA thinking.
我们目前也面临着类似的情况。 我们确定了人们可能希望在数据级别创建实时连接的不同场景。 在这种情况下，他们可以访问单个 Web 服务来请求和导入数据。
在某些时候，他们可能想要一个自定义用户界面（在我们的例子中是 Silverlight 2）。 对于这种情况，我们可以提供一个基类，并让它们在中央存储库中注册模块。 然后它以统一的方式集成到我们的应用程序中，包括安全性、形式和行为以及与服务的交互。
We are currently in a similar situation. We identified different scenarios where people may want to create a live connection on a data level. In that case they can have access to a sinle webservice to request and import data.
At some point they may want to have a custom user interface (in our case Silverlight 2). For this scenario we can provide a base class and have them register the module in a central repository. It then integrates into our application in a uniform way, including security, form and behaviour and interaction with services.