C#插件功能的模式/方法我正在开发一个新产品，最终会根据客户的个性化需求围绕它构建不同的功能。所以我想实现部署插件的能力，核心应用程序将检测插件并相应地进行更改。问题是该产品有可能针对不支持System.Addin的早期版本的.Net或MEF。也就是说，哪种模式/编程方法非常适合支持C#中的插件？我想完全远离第3方框架，尽管可以自由命名它们。理想情况下，我希望能够插入插件、修改主菜单和/或上下文菜单和/或提供新服务。在Java中，这可以通过扩展点很好地处理。我基本上坚持编写自己的扩展点管理器吗？您需要查看System.Reflection命名空间来帮助您解决这个问题。一种方法是为您的插件类创建一个通用接口（查找策略模式），然后在运行时使用反射来查看给定文件夹（可能是exe所在的位置或特殊的加载项文件夹）中的所有dll。包含该特定的类界面。具体来说，保留一个类型化的字典（具有您的特殊接口的字典，将其指定为插件类）。一旦您拥有包含接口的类型列表（指定为插件），您就可以使用System.Activator类随意动态实例化它们。加载项类最初在应用程序启动时被探测，然后使用抽象工厂根据类型或使用.net属性归因于该类的其他元数据来加载插件。如果你想要特定的代码示例，我可以为你做，但是，如果你打算构建一个强大而灵活的插件系统，你应该花时间熟悉System.Reflection、System.Activator和.net特性。请享用！我是Java专家，但由于您的问题是关于软件设计模式的……策略模式很可能会在非常抽象的层面上为您提供帮助。所以，也许您的核心应用程序有一组非常基本的操作“策略”……您可以调用一个简单的菜单栏策略对象来为您创建菜单栏，而不是创建菜单栏。然后，提供一种交换策略的方法（因此部署插件本质上就是在受影响的对象上调用一堆setStrategy()方法，或者您喜欢的方式）。该插件将提供替代策略。至于插件类的运行时加载，我对C#不熟悉，无法回答这个问题。正如我之前所说，这一切都非常抽象。尽量避免反射——尽管有时是必要的，但使用反射具有性能、安全性和设计缺陷。希望有帮助！几乎所有的“插件”架构都将基于Builder模式的某些变体——几乎是根据定义。以上就是C#学习教程的全部内容：C#插件功能模式/方法分享。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。涉及侵权，请点击维权联系管理员删除。如需转载请注明出处：
