我应该将主要版本号放入C#/ Java命名空间吗？

Question

我正在为WCF Web服务设计一组"服务"层对象(数据对象和接口定义)(将由第三方客户端使用,即不在内部,因此在我的直接控制之外).

我知道我不会完全正确地获得接口定义 - 并且我想要准备时间,因为我知道我将不得不介绍一组新的数据对象.然而,我所处的世界的现实是,我还需要同时运行我的第一个版本.

我的服务的第一个版本将具有http://host/app/v1service.svc的 URL

当新版本到来时,它们将存在于 http://host/app/v2service.svc

但是,当谈到数据对象和接口时,我很想将接口号的"主要​​"版本放入类的实际命名空间中.

namespace Company.Product.V1
{
   [DataContract(Namespace = "company-product-v1")]
   public class Widget
   {
        [DataMember]
        string widgetName;
   }

   public interface IFunction
   {
       Widget GetWidgetData(int code);
   }
}

当需要对服务进行根本性改变时,我将介绍一些类似的课程

namespace Company.Product.V2
{
   [DataContract(Namespace = "company-product-v2")]
   public class Widget
   {
        [DataMember]
        int widgetCode;

        [DataMember]
        int widgetExpiry;
   }

   public interface IFunction
   {
       Widget GetWidgetData(int code);
   }
}

我认为它的优点是我可以使用一组代码为两个接口版本提供服务,并在可能的情况下共享功能.这是因为我将能够将两个接口版本作为一组不同的C#对象引用.类似地,客户端可以同时使用两个接口版本,可能在一些遗留代码中使用V1.Widget,而新位移动到V2.Widget.

有谁能说出为什么这是一个愚蠢的想法？我有一种唠叨的感觉,这有点臭...

注意:我显然不建议每个新版本的服务都在新的命名空间中.据推测,我将尽可能多地进行非破坏性的界面更改,但我知道我将在所有数据建模中可能需要进行重大改写.

我理解汇编版本控制等,但我认为这个问题与那种版本控制相关.但我可能是错的.

Answer 1

我已经按照您的方式完成了（使用V1、V2命名空间和Common命名空间）并且效果相当好。基本上，我在命名空间中实现了实际的代码Common，并且每个V1、V2等只是充当它的包装器。

就我们而言，旧版本通常会保留相当长的一段时间。通常，当客户端请求访问我们的 API 时，我们会向他们提供当时的“当前”版本，然后他们将永远使用该版本 - 除非有严重的业务案例需要迁移到新版本，否则他们几乎不会使用该版本。永远不会做。