當您的設定是帶有物體框架的OData時如何處理過度發布/發布不足

WEB API 中的正常路徑是擁有您的“物體”和“DTO”。例如

public class Product  // DB Entity
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string SerialNumber { get; set; }
    public string ReferenceNumber { get; set; }
    public DateTime RecordTimestamp { get; set; }
    public string InternalNumber { get; set; }
}

public class ProductDto  // Client-facing DTO
{
    public string Name { get; set; }
    public string SerialNumber { get; set; }
    public string ReferenceNumber { get; set; }
} 

在這種情況下，不僅是發布，而且查看也是問題。我們希望消費者看到部分資料并隱藏系統資料。但同時，相同的 Context 用于POSTing（由允許的帳戶），因此物體模型必須具有可用于 CRUD 的屬性。

正常的 OData API 設定如下 - 控制器派生自此可征服物件路由到的ODataController操作GET回傳IQueriable<T>DbSet<T>

傳遞 OData 查詢時，OData 控制器會發揮所有作用。GET但是在這種情況下，如果 DTO 模型與物體模型相同，我們如何隱藏我們不想顯示的屬性。

有沒有辦法通過屬性（模型系結？）來做到這一點，或者這種情況需要不同的物體用于 POST 和 GET？但即使我確實為我創建了單獨的物體，GET我仍然需要有Key欄位，因為 ODAta 使用這些屬性來建立它的關系。

uj5u.com熱心網友回復：

關于 DTO，OData 模型是您公開的所有型別的 DTO 映射。除非您的 DTO 顯著更改資料結構，否則無需使用其他 ORM 工具（如AutoMapper）或手動將 OData 查詢和模型工件映射到其 EF 對應項，或為業務物體公開您自己的 DTO。您應該在 OData 模型定義本身中執行此操作。

DTO 對于您希望向最終客戶端呈現完全不同的模式的復雜查詢很有用，該模式可能更適合特定流程或用戶體驗，但對于 CRUD 資料輸入管理不是必需的。

如何防止 OData 中的過度發布

過度發布意味著設定了比預期更多的屬性，可能允許內部使用或狀態欄位（如余額或限制欄位或Appproval標志）被客戶端故意操縱。

如果客戶端根本不需要某些欄位，那么我們可以從 OData Schema 中完全洗掉這些欄位，從而有效地創建一個省略這些屬性的 DTO 定義。

第一種原則方法是在注冊型別并將它們系結到s后，使用 OData Fluent Configuration API 故意排除特定欄位：EntitySet

var productConfig = builder.EntityType<Product>();
productConfig.Ignore(x => x.RecordTimestamp);
productConfig.Ignore(x => x.InternalNumber);

不幸的是，在 .Net FX 中，這些Ignore方法是不可鏈接的……我們也不能使用NotMappedAttribute，因為這會專門從 EF 背景關系和資料庫中洗掉該欄位。

不要從 OData 模型中排除關鍵屬性，這樣做會使單個資源的尋址顯著復雜化，并且在許多情況下會破壞 OData 運行時。

如本文IgnoreDataMemberAttribute所述，如果您使用的是ODataConventionModelBuilder. 這就是它的樣子：

public class Product  // DB Entity
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string SerialNumber { get; set; }
    public string ReferenceNumber { get; set; }
    [IgnoreDataMember]
    public DateTime RecordTimestamp { get; set; }
    [IgnoreDataMember]
    public string InternalNumber { get; set; }
}

如何防止張貼不足

與 MVC 實作一樣，RequiredAttribute可用于要求特定欄位包含在針對特定物體的 POST/PATCH 中。但只有在使用時才會自動應用ODataConventionModelBuilder，否則您需要明確設定：

var productConfig = builder.EntityType<Product>();
productConfig.HasRequired(x => x.Name);

如果您使用的是，ODataConventionModelBuilder您可以直接注釋模型：

public class Product  // DB Entity
{
    public int Id { get; set; }
    [Required]
    public string Name { get; set; }
    public string SerialNumber { get; set; }
    public string ReferenceNumber { get; set; }
    [IgnoreDataMember]
    public DateTime RecordTimestamp { get; set; }
    [IgnoreDataMember]
    public string InternalNumber { get; set; }
}

在考慮或測驗Under Posting時，請記住 ODataPATCH專門設計用于客戶端僅發送應更改的屬性，請求中未提供的屬性PATCH應保持不受影響，但仍應將請求作為有效處理只要包含所有必需的屬性，就可以請求。

條件邏輯

您還可以在控制器實作中的 PATCH 處理程式中顯式驗證Under或Over post 約束。這對于實作基于自由裁量權的驗證邏輯很有用，可能取決于分配給用戶的安全規則或角色。如果您希望在客戶端中將內部值用于某些操作（可能是只讀的），或者您希望僅允許通過具有其他標準或安全約束的特定端點更新某些欄位，它也很有用。 .

/// <summary>
/// Update an existing item with a deltafied or partial declared JSON object
/// </summary>
/// <param name="key">The ID of the item that we want to update</param>
/// <param name="patch">The deltafied or partial representation of the fields that we want to update</param>
/// <param name="options">Parsed OData query options, not used directly but assists method pattern matching for swagger doc generation</param>
/// <remarks>PATCH: odata/DataItems(5) { "Property" : "Value" }</remarks>
/// <returns>UpdatedOdataResult</returns>
[EnableQuery(AllowedQueryOptions = AllowedQueryOptions.DeltaToken | AllowedQueryOptions.Format | AllowedQueryOptions.Select)]
[AcceptVerbs("PATCH", "MERGE")]
public virtual async Task<IHttpActionResult> Patch([FromODataUri] TKey key, Delta<TEntity> patch, ODataQueryOptions<TEntity> options)
{
    // Validate RequiredAttribute and other Edm Model constraints
    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    if (patch == null)
        throw new ArgumentNullException("patch", "Ensure that incoming structure is valid JSON and that you do not attempt to patch nested properties, this controller does not support that");

    var itemQuery = db.Products.Where(x => x.Id == key);

    // simple concurrency check - only works if ETag is provided in the request
    if (options.IfMatch != null &&
        !options.IfMatch.ApplyTo(itemQuery).Any())
    {
        return StatusCode(HttpStatusCode.PreconditionFailed);
    }

    var item = itemQuery.FirstOrDefault();
    if (item == null)
    {
        return NotFound();
    }

    // TODO: validate conditional Under/Over POST constraints
    //       or constraints not declared in the Edm Model

    // don't allow edits to Name via this interface
    if (patch.GetChangedPropertyNames().Contains())
        return BadRequest($"{nameof(Product.Name)} cannot be modified via PATCH, please use the RenameProduct action instead");

    // Apply the properties to the underlying object
    patch.Patch(item);

    // Validate that one of SerialNumber OR ReferenceNumber are specified.
    // This does not mean that they were provided in the PATCH, only that after the PATCH, in the data model at least one of these properties has a value
    if (String.IsNullOrEmpty(item.SerialNumber) && String.IsNullOrEmpty(item.ReferenceNumber))
        return BadRequest($"One of {nameof(Product.SerialNumber)} OR {nameof(Product.ReferenceNumber)} must have a value!");

    // After validation, commit the change to the database
    try
    {
        await db.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException)
    {
        if (itemQuery.Count() == 0)
            return NotFound();
        else
            throw;
    }

    return Updated(item);
}

這個例子比很多例子都詳細，但是展示標準實作很重要，而不是像檔案中常見的那樣只展示它的一部分。我希望這能推動后續問題；）

更多關于 DTO

我們有時會在網上看到使用AutoMapper等工具而不是正確配置 OData 模型的 OData 實作示例。有時這僅僅是因為與AutoMapper相比，配置邏輯有時比較麻煩。其他實體是從已經實作AutoMapper的先前業務域存盤庫轉換的 API（或開發人員）的示例。有時只是功能沒有被很好地理解。

ODataConventionModelBuilder的設計目的不是讓開發人員有機會挑選要實作的特定約定，也不允許您添加自己的自定義約定 OOTB。這使得社區更難適應該領域的配置，并且由于生產作業負載的代表性不足并因此支持查詢，因此在提供的檔案中對此的參考很少。

如果您確實將 DTO 手動映射到 EF 背景關系，那么 OData 模型 DTO 將代表您的內部 DTO 到外部呼叫者的 1:1 映射。這對性能的影響可以忽略不計，但它是額外的配置層，因此在許多情況下 OD??ata API 不需要管理。

如果過帳/過帳不是問題

如果 DTO 的主要驅動因素是性能，那么 OData 解決方案是實作一個$select查詢引數以僅回傳您需要的欄位，我們不需要為此實作特定的 DTO。

使用 OData $Select 優化 Web 應用程式
OData $select 使 API 使用者能夠在資料從他們呼叫的 API 端點回傳之前塑造他們正在使用的資料。

這允許客戶端限制應該回傳的資料，但允許服務器實作執行此操作的邏輯，主要是為了減少服務器和客戶端之間傳輸的位元組數。

使用 EF 支持的控制器實作IQueryable允許對特定欄位的請求以修改后的 SQL 查詢的形式延遲到支持資料存盤，僅將這些欄位從資料庫傳輸到 API，然后再傳輸到客戶端。為我們提供來自資料庫和API 的改進回應。

當呼叫客戶端知道它需要顯示的特定欄位時，允許客戶端管理是合適的$select，在這種情況下$select=Name,SerialNumber,ReferenceNumber

您還可以管理默認值，$select以應用于客戶端未指定$select. 但是，如果您這樣做，您的客戶端將需要顯式呼叫$select=*以確保回傳所有欄位，或者特別包括關鍵欄位，在這種情況下Id，如果您還沒有該資訊。

注意：如果您從客戶端創建或更新邏輯不直接為隱藏欄位提供值并且不需要它們來驅動 UI 邏輯，那么我們可以將它們從 OData 背景關系中完全洗掉。服務器實作仍然可以訪問整個 EF 模式以通過 OData API 處理 CRUD 請求，如果您在客戶端中不需要它們，則無需將它們包含在客戶端背景關系中！

標籤：。网实体框架asp.net-web-api数据数据控制器

上一篇：是否可以在物體框架中將參考型別轉換為值型別？

下一篇：當IDENTITY_INSERT設定為OFF時，無法在表中插入標識列的顯式值-EFCore多對多（子）資料