sollte ich jemals eine Hauptversionsnummer in einen C#/Java Namespace setzen?

Question

Ich entwerfe eine Reihe von 'Service'-Layer-Objekten (Datenobjekte und Schnittstellendefinitionen) für einen WCF-Webdienst (der von Drittanbietern verbraucht wird, d. H. Nicht intern, also außerhalb meiner direkten Kontrolle).

Ich weiß, dass ich bin nicht die Schnittstellendefinition erhalten würde genau richtig - und sind will für die Zeit vorbereiten, wenn ich weiß, dass ich werde eine Bruch Reihe neuer Datenobjekte einzuführen. Allerdings ist die Realität der Welt, in der ich bin, dass ich auch meine erste Version gleichzeitig für eine ganze Weile laufen muss.

Die erste Version meines Dienstes wird URL haben von http://host/app/v1service.svc

und wenn die Zeiten durch eine neue Version kommt, wird leben in http://host/app/v2service.svc

Wenn es jedoch auf die Datenobjekte und Schnittstellen kommt, ich Ich spiele mit der 'großen' Version der Schnittstellennummer in den tatsächlichen Namespace der Klassen.

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

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

Wenn die Zeit in den Dienst für eine grundlegende Veränderung kommt, werde ich einige Klassen wie

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

Die Vorteile vorstellen, wie ich es sehe, dass ich in der Lage sein wird, eine einzelne haben Code-Set für beide Schnittstellenversionen, Freigabe der Funktionalität wo möglich. Dies liegt daran, dass I in der Lage sein wird, beide Schnittstellenversionen als separate Menge von C# -Objekten zu referenzieren. Ebenso können Clients beide Versionen der Schnittstelle gleichzeitig verwenden, möglicherweise unter Verwendung von V1.Widget in einem älteren Code , während neue Bits auf V2.Widget übertragen werden.

Kann jemand sagen, warum das eine dumme Idee ist? Ich habe eine nagende Gefühl , dass dies ein wenig muffig ist ..

Hinweise: Ich bin natürlich nicht jede einzelne neue Version des Dienstes schlägt würde in einem neuen Namensraum liegen. Vermutlich werde ich so viele nicht-brechen Schnittstellenänderungen wie möglich tun, aber ich weiß, dass ich einen Punkt treffen wird, wo alle Datenmodellierung wahrscheinlich eine signifikante Neuschreibung benötigen wird.

Ich verstehe Montage Versionierung usw., aber ich denke, diese Frage ist tangential zu dieser Art der Versionierung. Aber ich könnte falsch liegen.

Answer 1

Ich habe es so gemacht, wie Sie haben (mit V1, V2 Namespaces und Common Namensraum) und es ist ziemlich gut ausgearbeitet.Grundsätzlich habe ich den tatsächlichen Code im Common Namespace implementiert und jeder der V1, V2, etc. einfach als Wrapper um es herum.

In unserem Fall bleiben die älteren Versionen typischerweise längere Zeit bestehen. Normalerweise, wenn ein Client Zugriff auf unsere API anfordert, geben wir ihnen die "aktuelle" Version zu der Zeit und dann werden sie diese für immer verwenden - es sei denn, es gibt einen ernsthaften Geschäftsfall für den Wechsel zu einer neueren Version, dann ziemlich Tue niemals.

Answer 2

Normalerweise habe ich gesehen (und habe mich selbst) einfach Version 2 Widget2, IWidget2 usw. aufgerufen. Wenn Sie erwarten, dass v2 (wahrscheinlich) das Ende sein wird, basierend auf den Erfahrungen aus dem Sehen von V1 in freier Wildbahn ist in der Regel in Ordnung. Aber wenn Sie erwarten, dass es sich eher um eine sich ständig entwickelnde Sache handelt, denken Sie vielleicht an einen flüssigeren Vertragsansatz.