使用WCF和System.AddIn的应用程序架构

Question

一点背景 - 我们正在设计一个使用客户端/服务器架构的应用程序：

• 加载服务器端模块的服务器，可能由其他团队开发。
• 加载相应客户端模块的客户端（也可能由其他团队开发;每个客户端模块对应一个服务器模块）。
• 客户端与服务器端进行通信以进行一般协调，以及模块特定任务。 （此时，我认为这意味着客户端与服务器通信，客户端模块与服务器模块通信。）
• 环境是.NET 3.5，客户端是WPF。

部署方案引入了独立升级服务器，任何服务器端模块，客户端和任何客户端模块的潜力。但是，需要能够使用不匹配的版本“工作”。因此，我担心版本问题。

到目前为止我的想法：

• 服务器的Windows服务。
• 使用System.AddIn加载服务器并与服务器模块通信将使我们在服务器和服务器模块之间的版本兼容性方面具有最大的灵活性。
• 服务器和每个服务器模块提供WCF服务以便与客户端通信;服务器和服务器模块之间或两个服务器模块之间的通信使用AddIn合同。 （这样做的一个优点是模块可以在服务器内部及其外部公开不同的接口。）
• 同样，客户端使用System.AddIn查找，加载客户端模块并与之通信。
• 客户端与客户端模块的通信是通过AddIn接口进行的;从客户端以及从客户端模块到服务器端的通信都是通过WCF进行的。
• 为了获得最大的弹性，每个模块将在一个单独的应用程序域中运行。
• 通常，系统具有适度的性能要求，因此预计编组和交叉过程边界不会成为性能问题。 （性能要求基本上归结为：不要妨碍此处未描述的系统的其他部分。）

我的问题围绕着使用两种不同的通信和版本控制模型的想法，这将对我们的开发人员造成额外负担。 System.AddIn似乎相当强大，但也有点笨拙。 （我也不确定微软将来对它的承诺。）另一方面，我对WCF的版本控制能力并不感到兴奋。我觉得可以在WCF中实现System.AddIn视图/适配器/合同系统，但对于这两种技术来说都是新手，我不知道从哪里开始。

所以......我在这里走在正确的轨道上吗？我这么做难吗？在这条路上我有需要注意的问题吗？

感谢。

Answer 1

这听起来太复杂了。考虑一个体系结构，其中每个添加的模块都包含客户端代码（如果您愿意，请使用System.AddIn），但服务器端模块是新的service.svc文件。客户端将知道相应服务的URL。

或者，您应该查看Microsoft扩展性框架（MEF）以获取加载项功能。这就是他们将在即将发布的版本中开始用于Visual Studio可扩展性的内容。