C＃ - Prism for WPF - 通用模块的库升级策略

Question

我正在设计一个使用Prism模式的复合WPF/MVVM应用程序。我已阅读WPF的Developer's Guide to Microsoft Prism Library 5.0，并且我熟悉所描述的大多数模式。

我的应用程序的模块将包含许多二进制文件（DLL-S）的，其中一些将包括实施的事件聚合和服务共享库，它将定义公共接口到MVVM模型，事件类通过该模块。其他模块将能够引用这样一个库，并通过公共接口和IoC与其模型，事件和服务一起工作。

比方说ModuleA.Shared共享库包括其的SampleModel和SampleService，这与的SampleModel执行工作的一个公共接口：

namespace ModuleA.Shared 
{ 
    interface ISampleModel 
    { 
     int SampleProp01 { get; set; } 
     int SampleProp02 { get; set; } 
    } 

    interface ISampleService 
    { 
     ISampleModel GetSampleModelInstance(); 
     void SaveSampleModelInstance(ISampleModel obj); 
    } 
} 

现在说ModuleB（在非共享二进制）使用ModuleA的公共图书馆：

namespace ModuleB.Engine 
{ 
    class SampleClass 
    { 
     void SampleMethod() 
     { 
      ModuleA.Shared.ISampleService srvc = SomeIoCContainer.Resolve<ModuleA.Shared.ISampleService>(); 
      ModuleA.Shared.ISampleModel obj = srvc.GetSampleModelInstance(); 

      // Do some work on obj... 

      srvc.SaveSampleModelInstance(obj); 
     } 
    } 
} 

好了，现在让我们说ModuleB开发和利用第三方（如第三方插件）编程和维持。在某个时间点我添加一个新的属性，以ModuleA.Shared.ISampleModel：

namespace ModuleA.Shared 
{ 
    interface ISampleModel 
    { 
     int SampleProp01 { get; set; } 
     int SampleProp02 { get; set; } 
     int NewProp { get; set; } // <-- New property 
    } 

    /* ... */ 
} 

最终用户升级我的应用程序，所以老ModuleA的可执行文件已经被新的所取代。 ModuleB由第三方分发，其二进制文件保持不变。

由于ModuleA和ModuleB正与不同版本的编译ModuleA.Shared.ISampleModel，我认为国际奥委会解决将不会成功，应用程序将在一个异常结束。

我在问什么是解决此类问题的良好实践/模式？如何让一些模块升级而不破坏对依赖它们的第三方模块的支持，并且使用它们的共享库的旧版本进行构建？

Answer 1

这与您是否使用棱镜完全无关。你正在提供一个插件API（通过使用棱镜的模块解构），你必须计划版本化你的api。

首先，一旦api的一个版本被释放，它就会被冻结。你永远无法触及它（除非你希望你的第三方重新编译所有东西，使他们和你的客户不高兴，至少可以说）。

而不是改变的API，发布它的新版本：

interface ISampleModelV1 
{ 
    int SampleProp01 { get; set; } 
    int SampleProp02 { get; set; } 
} 

成为

interface ISampleModelV2 
{ 
    int SampleProp01 { get; set; } 
    int SampleProp02 { get; set; } 
    int NewProp { get; set; } // <-- New property 
} 

那么第三方可以决定是继续使用ISampleModelV1或切换到ISampleModelV2如果他们需要NewProp。当然，你的应用将不得不支持他们两个。

由于随着api版本数量的增加，迟早会变得丑陋，您可能希望废弃旧版本，例如，如果你的应用从2.5到3.0，你可以取消对api 1.x的支持......尽管如此，一定要尽早将这些决定传达给客户和第三方。

BTW：

挑战棱镜没有解决 [...]应用版本