ASP.NET MVC API與Web API異步

Question

我目前正在使用ASP.NET MVC和單個控制器進行「API」排序。我正在使用從每個操作方法調用的服務/存儲庫模式。

類似於下面：

存儲庫：

public IQueryable<Order> GetOrders() 
    { 
     return from sqlOrder in DB.Orders 
       select new Order 
       { 
        Id = sqlOrder.Id, 
        Name = sqlOrder.Name, 
        Price = sqlOrder.Price 
       }; 
    } 

服務：

public List<Order> GetOrders() 
    { 
     return Repo.GetOrders().ToList(); 
    } 

控制器/操作：

public JsonResult GetOrders() 
    { 
     var orders = Service.GetOrders(); 

     return Json(orders, JsonRequestBehavior.AllowGet); 
    } 

一切是偉大的工作，但我考慮轉移到WEB API和異步/等待

類似如下：

庫：（無變化）

public IQueryable<Order> GetOrders() 
    { 
     return from sqlOrder in DB.Orders 
       select new Venue 
       { 
        Id = sqlOrder.Id, 
        Name = sqlOrder.Name, 
        Price = sqlOrder.Price 
       }; 
    } 

服務：

public async Task<List<Order>> GetOrders() 
    { 
     return await Repo.GetOrders().ToListAsync(); 
    } 

控制器/行動：

[ResponseType(typeof(List<Order>))] 
    public async Task<IHttpActionResult> GetOrders() 
    { 
     var orders = await Service.GetOrders(); 

     return Ok(orders); 
    } 

首先，有沒有這種異步/等待和Repository模式有問題嗎？

使用原始MVC框架作爲端點的「API」有什麼主要缺點嗎？而不是使用「Web API」？

Answer 1

你幾乎回答了你自己的問題:)

通過使用異步/等待IIS工作線程可以重新使用一個線程。假設你的api正在接收1000次/秒。如果您的線程限制設置爲100，則900個呼叫將等待空閒，直到請求完全結束。

然而，通過使用async/await，線程將盡早分配給900個等待請求，並且加載將更快（更難）到達您的數據庫。

想象一下，您的最大線程數爲1，1 db調用會持續10秒，並且服務器可以在50ms內從webrequest啓動數據庫調用。
通過使用異步你可以觸發200分貝的電話（每50毫秒1），如果你不釋放該線程，則爲1。

至於你的第二個問題：大多數人不會在他們的控制器內部做他們的數據訪問，但它使得一個非常簡單易懂的例子。
如果我的項目很簡單（想想網格屏幕），我甚至更喜歡在控制器內部使用EF語句來創建DAL層。
不要忘記，EF本身就是一個存儲庫，它甚至有一個工作單位... ...

編輯
這的確是來包裝你businessLogic從控制器一個單獨的層一個好主意。
您可以使用服務併爲每個要查詢的查詢公開一種方法，但我一直沿着這條道路前進，而且通常我發現我的服務臃腫得相當快，因爲​​開發人員在他們認爲合適的地方使用越來越多的方法。

最近我採用了命令查詢系統。查詢只是返回數據而命令只是做一些事情。分離有助於保持代碼清潔，並且開發人員更多地考慮創建全新的queryClass，就像他們創建一個方法時一樣（即使影響相同）。

我通常讓我的查詢有點動態，但不是太多。
例如，一個OrderQuery可以包含2個構造函數，其中1個使用customerID，1個使用typeID），然後查詢會應用更多的過濾器或更少的過濾器，具體取決於構造方式。
如果我需要說所有的銷售價值超過X的最新訂單，我可能會創建一個新的查詢GetOrdersByValue。
通過這種方式，查詢本身可以保持清潔和集中（這導致更快的速度，開發人員不會重新審視輪子，因爲他們認識到他們的請求應該已經存在）。