dovrei mai inserire un numero di versione principale in uno spazio dei nomi C#/Java?

Question

Sto progettando un set di oggetti layer 'servizio' (oggetti dati e definizioni interfaccia ) per un servizio Web WCF (che verrà consumato da client di terze parti, ad esempio non all'interno dell'azienda, quindi fuori dal mio controllo diretto).

So che io sono non andare per ottenere la definizione di interfaccia esattamente a destra - e sto volendo prepararsi per il momento in cui so che dovrò introdurre una serie di rottura di nuovi oggetti dati. Tuttavia, la realtà del mondo in cui mi trovo è che dovrò anche eseguire la mia prima versione contemporaneamente per un po 'di tempo.

La prima versione del mio servizio avrà URL del http://host/app/v1service.svc

e quando i tempi arriva dalla nuova versione vivrà a http://host/app/v2service.svc

Tuttavia, quando si tratta di oggetti di dati e interfacce, I sto giocando con la versione "principale" dell'interfaccia numero nello spazio dei nomi effettivo delle classi.

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

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

Quando arriva il momento per un cambiamento fondamentale al servizio, vi presenterò alcune classi come

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

I vantaggi come la vedo io è che sarò in grado di avere un unico set di codici che servono entrambe le versioni dell'interfaccia, condivisione delle funzionalità ove possibile. Questo perché I sarà in grado di fare riferimento a entrambe le versioni dell'interfaccia come un insieme distinto di oggetti C# . Allo stesso modo, i client possono utilizzare simultaneamente entrambe le versioni dell'interfaccia , magari utilizzando V1.Widget in qualche codice legacy mentre i nuovi bit passano a V2.Widget.

Qualcuno può dire perché questa è un'idea stupida? Ho la sensazione fastidiosa che questo è un po 'puzzolenti ..

note: Non sto ovviamente proponendo ogni singola nuova versione del servizio di sarebbe in un nuovo spazio dei nomi. Presumibilmente farò il maggior numero possibile di modifiche all'interfaccia senza interruzioni, ma so che I colpirà un punto in cui tutta la modellazione dei dati avrà probabilmente bisogno di una riscrittura significativa .

Capisco il controllo delle versioni di assieme, ma penso che questa domanda sia tangente a quel tipo di controllo delle versioni. Ma potrei sbagliarmi.

Answer 1

ho fatto il modo che hai (con V1, V2 spazi dei nomi e uno spazio dei nomi Common) e ha funzionato abbastanza bene.Fondamentalmente, ho implementato il codice effettivo nello spazio dei nomi Common e ciascuno di V1, V2, ecc. Funziona semplicemente come un wrapper attorno ad esso.

Nel nostro caso, le versioni precedenti rimangono in genere per un po 'di tempo. Di solito, quando un cliente richiede l'accesso alla nostra API, gli daremo la versione "corrente" al momento e poi lo useranno per sempre - a meno che non ci sia un serio caso aziendale per passare a una versione più recente, quindi sono più o meno mai fare.

Answer 2

In genere ho visto (e fatto me stesso) semplicemente chiamando la versione 2 Widget2, IWidget2, ecc. Se ci si aspetta che v2 sia (probabilmente) il fine-tutto, basato sulle lezioni apprese dal vedere v1 in the wild, che di solito va bene. Ma se ti aspetti che sia più una cosa in continua evoluzione, forse pensa a un approccio contrattuale più fluido.