C#-WPF棱镜-通用模块的库升级策略 [英] C# - Prism for WPF - Common modules' libraries upgrading strategy

问题描述

我正在使用Prism模式设计复合WPF/MVVM应用程序.我已经阅读了用于WPF的Microsoft Prism Library 5.0开发人员指南并且我熟悉所描述的大多数模式.

I'm designing a composite WPF/MVVM application using Prism patterns. I've read the Developer's Guide to Microsoft Prism Library 5.0 for WPF and I am familiar with most of the patterns described.

我的应用程序的模块将包含许多二进制文件(dll-s)，其中一些将包含共享库，该库将定义MVVM模型的公共接口 ，事件聚合器的事件类以及由该模块实现的服务.其他模块将能够引用这样的库，并通过公共接口和IoC来使用其模型，事件和服务.

My application's modules will consist of a number of binaries (dll-s) and some of them will include a shared library, which will define public interfaces to MVVM models, event classes for event aggregator and services implemented by that module. Other modules would be able to reference such a library and work with its models, events and services through public interfaces and IoC.

让我们说 ModuleA.Shared 共享库为其 SampleModel 和 SampleService 包含一个公共接口，该接口与 SampleModel :

Let's say ModuleA.Shared shared library includes a public interface for its SampleModel and SampleService, which performs work with SampleModel:

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

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

现在说 ModuleB (在非共享二进制文件中)使用 ModuleA 的公共库:

Now say ModuleB (in a non-shared binary) uses ModuleA's public library:

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 :

Okay, now let's say ModuleB is developed and mantained by a third-party (like a third-party plugin). At some point in time I add a new property to ModuleA.Shared.ISampleModel:

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

    /* ... */
}

最终用户升级了我的应用程序，因此旧的 ModuleA 二进制文件被替换为新的二进制文件. ModuleB 由第三方分发，其二进制文件保持不变.

The final user upgrades my application, so the old ModuleA's binaries get replaced with the new ones. ModuleB is distributed by a third-party and its binaries stay the same.

由于现在已使用不同版本的 ModuleA.Shared.ISampleModel 编译了 ModuleA 和 ModuleB ，我认为IoC解析将不会成功，并且应用程序将以异常结束.

Since ModuleA and ModuleB are now compiled with different versions of ModuleA.Shared.ISampleModel, I assume IoC resolving will not succeed and the application will end in an exception.

我要问的是解决此类问题的良好做法/模式是什么?如何在不破坏对第三方模块的支持的前提下使某些模块可升级，而第三方模块依赖于它们，并且是使用较旧版本的共享库构建的?

What I am asking is what are the good practices / patterns for resolving this kind of issuses? How to make some modules upgradable without breaking the support for third-party modules which depend on them and were built with an older version of their shared libraries?

推荐答案

这与是否使用棱镜完全无关.您正在提供插件api(通过使用Arizona的模块不可靠)，并且必须计划对api进行版本控制.

This is completely independent of whether you use prism or not. You're providing a plugin api (through the use of prism's module disconvery), and you have to plan for versioning your api.

首先，一旦发布了api版本，它就会被冻结.您永远无法触摸它(除非您希望第三方重新编译所有内容，至少可以使他们和您的客户不满意).

First of all, once a version of the api is released, it's frozen. You cannot ever touch it (unless you want your third parties to recompile everything, making them and your customers unhappy, to say the least).

而不是更改 API，而是发布该API的新版本:

Instead of changing the api, release a new version of it:

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或如果需要NewProp则切换到ISampleModelV2.当然，您的应用程序必须同时支持它们.

A third party can then decide to either continue to use ISampleModelV1 or switch to ISampleModelV2 if they need NewProp. Your app, of course, will have to support both of them.

随着api版本数量的增加，这种情况迟早会变得很难看，您可能要弃用旧版本，例如如果您的应用从2.5升级到3.0，则可以删除对api 1.x的支持...不过，请务必尽早将这些决定告知客户和第三方.

As this gets ugly sooner or later as the amount of api versions increases, you might want to deprecate the old ones, e.g. if your app goes from 2.5 to 3.0, you could remove support for api 1.x... be sure to communicate these decisions to customers and third parties early enough, though.

顺便说一句:

棱镜无法解决的挑战 [...]应用程序版本控制

Challenges Not Addressed by Prism [...] Application versioning

这篇关于C#-WPF棱镜-通用模块的库升级策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！