Question

我对API和版本控制还很陌生，但据我了解，如果API的合同发生变更，开发人员（应该是我）应该保留代码。如果我错了，请纠正我，但我将模型更改视为违反合同的更改。

所以我的问题是-您只是为了版本控制而创建新模型（例如ModelName.V2）吗？有一个更好的方法吗？这意味着即使我的模型中的属性稍有变化，也意味着我将其迭代到另一个版本。

p.s。让我知道是否需要编辑我的问题，因为我在StackOverflow中还很新。

样品

public class Product
{
    public int ID {get;set;}
    public string Name {get;set;}
}

和随附的控制器

[ApiVersion("1.0")]
[Route("api/v{version:apiVersion}/[controller]/[action]")]
public class Products : Controller
{
   Product[] prod = new Product[]{
       new Product(){ID = 1, Name = "T-Shirt"},
       new Product(){ID = 2, Name = "Jeans"}
   };


   [HttpGet]
   [ActionName("gotcha")]
   public IActionResult GetProduct()
   {
       return Ok(prod);  
   }
}

以及用于V2控制器

[ApiVersion("2.0")]
[Route("api/v{version:apiVersion}/[controller]/[action]")]
public class V2.Products : Controller
{
       [HttpGet]
       [ActionName("gotcha")]
       public IActionResult GetProduct()
       {
           var trash = "Hello World!";
           return OK(trash);  
       }
}

上面的代码是我理解为合同违约和所需版本控制的内容，下面是我的模型合同违约问题：

public class Product
{
   public int ID {get;set;}
   public string Name {get;set;}
   public decimal Price {get;set;}
}

因此，上面的示例显示我添加了一个新属性。我认为这是合同违约，是否要迭代新的控制器版本，然后再保留旧的Model？如果将来保留旧版本，将来会很混乱。

Answer 1

当我进行API版本控制时。我添加了带有版本号的新模型，以便能够跟踪数据数据结构中的更改，例如：

public class ProductV2
{
        //New attributes
}

如果新模型与旧模型相似，再加上新属性，我将继承先前版本的属性：

public class ProductV2 : Product
{
        //New attributes
}

希望这次我能理解您的问题。

Answer 2

首先，只有发生重大更改时，您才需要还原。并非所有事物都一定是一项重大更改，通常添加新属性实际上并不是一项重大更改。过时的客户应该简单地忽略它，如果不是，则在客户上比您更多，因为他们会做一些奇怪/错误的事情来导致任何事情中断。您需要更加关注更改或删除，从客户的角度来看，更改或删除是一回事。进行更改后，就好像旧属性已被删除而新属性已被添加一样。即使这样，也仅在名称或类型更改时才重要。幕后处理都没有关系，从技术上讲，即使您更改了属性名称，也可以使用JsonProperty属性之类的东西来使序列化返回旧名称。

假设您做了重大更改，那么是的，您应该创建模型类的新版本，并可能要创建一个新的动作/控制器，并以新版本命名数字，例如Product2和GetProduct2和/或Product2Controller，等等。是的，这可能导致代码重复，但是您可以做两件事来最小化它：

尽可能使用继承。例如，Product2可以从Product继承而只是覆盖需要更改的任何属性。如果仅添加新的GetProduct2操作，则可以将GetProduct的原始代码分解为私有通用方法GetProduct2<TProduct>，然后重新实现原始（和新的）方法以简单地返回即return GetProduct<Product>();和return GetProduct（）;。这些仅仅是示例。处理此问题的方法有很多，但要点是，它不一定需要主要的代码重复才能进行版本控制。
如果您发现代码库开始变得混乱，则可以开始弃用API版本。向您的客户发出通知，告知您最旧的一个或多个版本已被弃用。然后，经过一段合理的时间（取决于更新所需的复杂性），在新版本中删除旧代码。这当然会打断任何过时的客户，但会事先警告他们并给他们时间来进行更改，因此如果他们不这样做，那就在他们身上。您会发现所有大个子都不时这样做。我知道我已经收到来自Facebook的大量电子邮件，警告即将删除API版本。本质上，这就是他们在幕后所做的：清理代码库。

API版本控制-如果模型更改，该怎么办

2 个答案: