我是 Blazor 服務器端應用程式的新手。我目前正在使用 Blazor 服務器端應用程式為我的客戶端創建 Web 應用程式。我想了解在 Blazor 服務器端應用程式中使用 Web API 的良好做法。我可以使用物體框架直接在 Blazor 服務器端應用程式中訪問資料，但同時，已經撰寫了用于訪問資料的 API。
我想知道，為什么我不應該使用這些 API 而不是在 Blazor 服務器端應用程式中連接 EF。
使用 EF 提取資料會比 API 快得多嗎？
我應該使用哪種方法來進行良好的編碼練習？
謝謝
uj5u.com熱心網友回復：
我曾與 Blazorserver-side和一起作業過web-assembly，雖然不是專家，但很高興分享我所知道的。
在 Blazor
web-assembly中，頁面在瀏覽器的客戶端呈現。您無權訪問資料庫。您將需要一個 Web API 來為應用程式提供所需的資料、身份驗證、上傳等。因此，在這種情況下，需要 Web API。但是，在 Blazor
server-side中，頁面是在服務器端呈現的，您可以訪問資料庫，可以直接進行身份驗證。因此，您可以完全訪問服務器以及檔案系統等。因此，在這種情況下不需要 Web API，這使得 Blazor 服務器端的開發更加容易。您仍然可以使用 WEB API，但如果您剛開始，則無需使您的開發復雜化。
我想知道，為什么我不應該使用這些 API 而不是在 Blazor 服務器端應用程式中連接 EF。使用 EF 提取資料會比 API 快得多嗎？
是的，直接使用 EF 比 Web API 更快。此外，如果您開始不使用 Web API 的 blazor 服務器端開發將使您的開發更容易，因為您可以完全訪問服務器，因此不需要端點。
uj5u.com熱心網友回復：
我想知道，為什么我不應該使用這些 API 而不是在 Blazor 服務器端應用程式中連接 EF。
API 是現代的嗎？它是否從底層資料管道中抽象出控制器？它是基于EF的嗎？請參閱下面的討論。
使用 EF 提取資料會比 API 快得多嗎？
當然可以。您已經消除了一層復雜性。
我應該使用哪種方法來進行良好的編碼練習？
誰知道。
在理想的設計中，控制器、UI 或您的測驗例程都是同一資料管道的消費者。它們通過抽象實作的介面與資料管道通信。您可以在不關心 UI 或控制器的情況下實作特定于存盤的資料管道。
Consumer => interface => persistant storage
Consumer => interface => Test In Memory database
Consumer => interface => API Controller(Consumer) => interface => persistant storage
Consumer => interface => MS SQL DB
Consumer => interface => another DB provider
這一切都在設計中。
這是（我的）一篇文章，演示了如何構建可以插入任何消費者端點的 CQS 資料管道（基于 Blazor 天氣預報）。我將它用于我的 Blazor 演示。在實作中，消費者是一組 XUnit 測驗，持久存盤是一個 In-Memory EF 資料庫 - https://www.codeproject.com/Articles/5340253/Building-a-Succincct-DotNetCore-CQS-Data-管道
uj5u.com熱心網友回復：
我剛剛在 Blazor Server 中構建了一個日歷應用程式，該應用程式嵌入在現有的 MVC 專案中。
對于 Blazor Server - 您可以直接使用 dbContext 或創建自己的服務層 - 但請確保您的 dbContext 由 dbContext 工廠或為每個請求實體化的新工廠提供服務。
你可以使用現有的 API，這在技術上沒有問題——這也是我的第一個方法，但是由于我已經有了 MVC 服務層，我決定不復制代碼并使用現有的服務。API 對于 Blazor Server 可能有點尷尬，您可能會遇到一些問題，例如您可能必須自己撰寫的身份驗證 - 因為您通常不會為 Blazor Server 使用 API，因為您可以直接訪問 DB。也就是說 - 你可以使用 API 而不是復制代碼，這可能會節省一些時間。這不是使用 Blazor Server 的推薦方式，但可以這樣做。
取決于“不要重復自己”規則對您是否更重要。
uj5u.com熱心網友回復：
- 向 Blazor 應用（或任何型別的 Web 應用）授予資料庫憑據通常被認為是不好的做法。將您的關注點分開會是更好的做法。保持 Blazor 應用程式為網頁提供服務，并創建一個 RESTful Web API 以將資料提供給該 Blazor 應用程式。
- 此外，創建 Web API 將為您帶來靈活性。例如，有一天您可能希望將 Blazor 服務器端應用程式轉換為 Blazor Web Assembly 應用程式。如果是這樣，沒問題 - 您只需重新連接應用程式以通過 REST 從 Web API 獲取資料。或者更好 - 如果你有一個全新的應用程式（網路應用程式或其他東西），（可能）用不同的堆疊撰寫？再次 - 沒有任何問題。您始終可以通過 REST 檢索該資料。
使用 EF 提取資料會比 API 快得多嗎？
是的，但可能不會明顯更快。我上面所說的優點應該勝過這種擔憂。
有關 Blazor 和 Blazor 服務器應用程式的關注點分離和最佳實踐的更多資訊，我鼓勵您觀看 Gill Cleeren 的 Pluralsight 課程，題為“Blazor：入門”；具體來說，第 3 節：“處理資料”。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/531574.html
標籤：实体框架asp.net-web-api建筑学blazor 服务器端关注点分离
上一篇：物體框架不要在查詢結果中包含列