解决方案是使用“实体”的多种表示。应用程序使用包括方法，逻辑等的规范表示。然后将其转换为适合在Azure中存储的类型，或存储实体的其他类型。
这确实需要相同数据的多个表示，但它确实增加了一些灵活性。如果您更改数据模型，则可以保留旧的Azure表示，以便您可以读取旧数据，同时在保存时使用新的实体类型。这类似于Data Transfer Object的概念。
要在类型之间进行转换，有几个选项：
1.在类型上使用开关
1.使用visitor pattern。这有一个好处，你可以 * 强制 * 为每一个应用程序类型创建一个azure类型。所以忘记的机会更少。
您可能希望为应用程序端的实体提供一些公共接口，这样编译器就可以帮助确保您只保存那些设计为要保存的对象。
一个非常简单的例子来说明这个想法：

public interface IMyEntity{}
public class MyEntity {};
public interface IEntityStorage{
    void Save(IMyEntity entity);
}

public class MyEntityAzure : ITableEntity {
    public MyEntityAzure(MyEntity entity){
        // copy properties etc.
    }
    public MyEntity ToModel(){
       // Convert back to application entity
    }
}
public class AzureStorage : IEntityStorage{
    private AzureStorage storage;
    public void Save(IMyEntity entity){
        switch(entity){
            case MyEntity  myEntity:
                storage.Save(new MyEntityAzure(myEntity));
                break;
            // All other entity classes
         }
     }
}

字符串

让你的界面完全基于你想让它实现什么，而不考虑实现。

public interface ICustomerService
{
    public Task AddNewCustomerAsync<T>(Customer customer);
}

字符串
一旦你完成了这一点，添加实现。

public class TableStorageCustomerService : ICustomerService
{
    public async<Task> AddNewCustomerAsync<T>(Customer customer)
    {
        //map your customer class to your table entity
        //save the table entity to your table storage
    }
}

型
正如你所看到的，在你的接口中根本没有实现细节，因为你只使用Customer，所以你可以自由地将它Map到你的服务实现中的数据库所需要的任何类。