使用 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 可扩展性的内容。