¿Debería poner un número de versión principal en un espacio de nombres C#/Java?

Question

Estoy diseñando un conjunto de objetos de capa 'servicio' (objetos de datos y definiciones de interfaz ) para un servicio web WCF (que se consumirán por clientes externos, es decir, no internos, por lo tanto fuera de mi control directo).

sé que soy no va a obtener la definición de interfaz exactamente a la derecha - y me he queriendo prepararse para el momento en que sé que voy a tener que introducir un conjunto ruptura de nuevos objetos de datos. Sin embargo, la realidad del mundo en el que estoy es que también necesitaré ejecutar mi primera versión simultáneamente por bastante tiempo.

La primera versión de mi servicio tendrá el URL de http://host/app/v1service.svc

y cuando llegue el momento de una nueva versión vivirá en http://host/app/v2service.svc

Sin embargo, cuando se trata de los objetos de datos e interfaces, lo estoy jugando con poner la versión 'principal' del número de interfaz en el espacio de nombres real de las clases.

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

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

Cuando llegue el momento de un cambio fundamental en el servicio, voy a introducir algunas clases como

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); 
    } 
} 

Las ventajas como la veo son que voy a ser capaz de tener una sola conjunto de código que sirve ambas versiones de interfaz, compartiendo la funcionalidad siempre que sea posible. Esto se debe a que I podrá hacer referencia a ambas versiones de interfaz como un conjunto distinto de de objetos C#. De manera similar, los clientes pueden usar ambas versiones de la interfaz simultáneamente, tal vez usando V1.Widget en algún código heredado mientras que los nuevos bits se mueven al widget V2.Widget.

¿Alguien puede decir por qué esta es una idea estúpida? Tengo una molesta sensación que esto es un poco mal ..

notas: Obviamente no estoy proponiendo cada nueva versión única del servicio estaría en un nuevo espacio de nombres. Presumiblemente, haré tantos cambios de interfaz sin interrupción como sea posible, pero sé que I alcanzará un punto donde todos los modelos de datos probablemente necesitarán una reescritura significativa .

Entiendo versiones de montaje etc, pero creo que esta pregunta es tangencial a ese tipo de control de versiones. Pero podría estar equivocado.

Answer 1

lo he hecho de la manera que tienes (con V1, V2 espacios de nombres y un espacio de nombres Common) y ha funcionado bastante bien.Básicamente, tengo el código real implementado en el espacio de nombres Common y cada uno de los V1, V2, etc. simplemente actúa como un envoltorio alrededor de él.

En nuestro caso, las versiones anteriores suelen permanecer por bastante tiempo. Por lo general, cuando un cliente solicita acceso a nuestra API, les damos la versión "actual" en ese momento y luego la usan para siempre, a menos que haya un caso comercial serio para pasar a una versión más nueva, entonces prácticamente nunca lo haces.

Answer 2

Normalmente he visto (y hecho) simplemente llamando a la versión 2 Widget2, IWidget2, etc. Si espera que v2 (probablemente) sea el final, en base a las lecciones aprendidas de ver v1 en la naturaleza, eso por lo general está bien. Pero si espera que sea algo que evoluciona continuamente, tal vez piense en un enfoque contractual más fluido.