WCF服务和插件架构 [英] WCF service and a plug-in architecture

问题描述

是否可以将插件架构与WCF服务一起使用？我已经阅读了一些关于插件架构的内容，但我并不完全确定我是否了解它的好处。我有一个简单的WCF Web服务，它基本上流入数据并流回一些数据;数据是xml。有人告诉我，通过利用插件架构，可以修改或添加服务的行为或功能。真的吗？在线是否有任何文档/示例可以指向正确的方向？

Is it possible to use a plug-in architecture with a WCF service? I''ve read up a little on plug-in architecture and I am not completely sure if I am understanding its benefit that much. I have a simple WCF web service, that essentially streams in data and streams some data back; the data is xml. Someone has told me that me the behavior or functionality of the service could be modified or added on to by taking advantage of a plug-in architecture. Is that true? Is there any documentation/examples available online to point me in the right direction?

推荐答案

好的，正如我所承诺的那样，有一些链接指向我过去的答案：



创建WPF使用可重新加载插件的应用程序...... [ ^ ]，

AppDomain拒绝加载程序集 [ ^ ]，

使用CodeDom生成代码 [ ^ ]，

C＃Reflection InvokeMember on existing instance [ ^ ]，

项目和DLL'：如何保留它们可管理？ [ ^ ]，

通过它的字符串表示从集合中收集类型 [ ^ ]。



很抱歉，上面提到的应用程序字段并不意味着WCF（但可能包含它）。我对上面提到的一些问题进行了如此详细的回答，主要是因为应用程序比你的情况更加确定。



现在，我只能添加一个几个注意事项。



当您需要卸载插件时，会出现插件架构最困难的技术问题。在某些应用程序中，它永远不需要，因此它使事情变得更简单。最有可能的是，你需要在你的领域，但我不能确定。



这是因为在.NET中不允许卸载程序集，非常明显安全原因。如果您需要在运行时实际更改某些插件，则只能在单独的应用程序域中加载插件程序集，然后卸载整个域。由于不同域的地址空间是完全隔离的，因此不会有任何已经卸载的调用的危险。这是解决方案同时也是一个难点，因为Application Domain只能通过IPC进行通信（那是否清楚？）。幸运的是， AppDomain 类为应用程序域通信提供了方便且非常简单的高度简化的IPC设施。



这里是与WCF相关的一些好消息： WCF已经是IPC。这意味着在适当的架构中，您可以引入插件组件并开发其使用机制而无需增加与域通信相关的额外复杂性：无论如何，它们将通过WCF信道进行通信。 经典.NET远程处理的状态相同。 （有些人声称经典.NET远程处理应该被认为是过时的，但我不能同意这一点，因为它可以在比较典型的情况下在更困难的情况下提供更好的灵活性。）



这对你有意义吗？如果你想得到一些想法，那么你的其他问题非常受欢迎。

-SA

OK, as I promised, some links to my past answers:

Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^],
C# Reflection InvokeMember on existing instance[^],
Projects and DLL''s: How to keep them managable?[^],
Gathering types from assemblies by it''s string representation[^].

Sorry that the application fields mentioned above did not imply WCF (but might include it). I answered in so great detail to some of the questions referenced above mostly because the applications were much more certain than in your case.

Right now, I can add just a couple of considerations.

The most difficult technical issue with the plug-in architectures appears when you need to unload a plug-in. In some applications, it is never needed, so it makes things way simpler. Most likely, you will need it in your field, but I cannot be sure.

This is because unloading of an assembly is not allowed in .NET, by pretty obvious safety reasons. If you need to actually change some plug-ins during run time, you can only load a plug-in assembly in a separate Application Domain and later unload the whole domain. As the address spaces of different domains are perfectly isolated, it involved no danger of invocation of anything already unloaded. This is resolution is at the same time a difficulty, because the Application Domain can only communication via IPC (is that clear?). Fortunately, the AppDomain class provides highly simplified IPC facilities convenient and pretty easy for Application Domain communications.

And here is some good news related to WCF: WCF is already the IPC. It means that in proper architecture, you can introduce plug-in assembly and develop the mechanism of its use without adding additional complexity related to domain communications: they will communicate via WCF channels anyway. The same states for "classical" .NET remoting. (Some claim that "classical" .NET remoting should be considered obsolete, but I cannot agree with that, because it can provide better flexibility in more difficult scenarios than the typical ones.)

Does it make any sense for your? If you are getting to some ideas, your further questions are quite welcome.

—SA

这篇关于WCF服务和插件架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！