簡單 RestApi 的這個 c# 代碼有什么問題？

Question

我收到反饋：

“代碼測試未達到預期水平，缺乏對異步、HTTP 客戶端以及一般軟件開發模式的理解。結構和測試不佳”

我真的很感激任何有助於理解問題所在的幫助，因為代碼有效，測試有效，並且涵蓋所有解決方案，老實說，我不知道他們期望什么。

我知道在 OOP 中代碼可以更抽象和更復雜，但我看不出使代碼比解決給定問題所需的更復雜的任何目的。

Answer 1

可以做的改進很少，不僅會遵循現代實踐，而且在某些情況下會簡化代碼：

使用IHttpClientFactory （以前根據請求實例化HttpClient被認為是一種不好的做法 - 請參閱此處和此處為什么，盡管現在情況有所改善，但也請參閱此）。 有關可能的使用模式，請查看文檔
使用強類型配置，例如使用選項模式

實際上沒有理由在您的代碼中使用GetAwaiter().GetResult() ，例如在WeatherController中：

 if (response.IsSuccessStatusCode) { var weatherResponse = response.Content.ReadFromJsonAsync<WeatherResponse>().GetAwaiter().GetResult();

Answer 2

在我看來，可以在這方面改進代碼：

這段代碼應該放在Service層。 這段代碼放在AstronomyController
```
 HttpClient httpClient = new(); var responseAstro = await httpClient.GetAsync(requestURIAstro);
```
通常，控制器不應該有任何邏輯。 它應該協調和編排服務。
如果這個Helper class 有StringHelper名稱，它將更具可讀性：
```
 public class StringHelper
```
因此可以得出結論，如果StringHelper的代碼片段將包含有助於使用int類型的代碼，那么它將違反SOLID 原則的單一責任原則。

使用GetResult()可能是死鎖的潛在原因

var r = response.Content.ReadFromJsonAsync<ErrorResponse>().GetAwaiter().GetResult();

所以最好使用await ：

 var r = await response.Content.ReadFromJsonAsync<ErrorResponse>(); // the other code is omitted for the brevity

最好按三重 A 模式編寫測試。 此外，在為控制器編寫代碼時，盡量使用抽象。 在此處閱讀有關如何測試控制器的更多信息
例如：
```
 public class HomeController: Controller { private readonly IBrainstormSessionRepository _sessionRepository; // the other code is omitted for the brevity
```
這里IBrainstormSessionRepository是一個抽象。 此外，閱讀這篇文章“ Unit testing best practices with .NET Core and .NET Standard ”非常有幫助。
測試中應避免使用多個Assert 。 Roy Osherove 的“The Art of Unit Testing”有一本非常好的書。 Osherove 警告的事情之一是單元測試中的多個斷言。 也就是說，人們通常應該避免編寫可能因不止一種原因而失敗的測試。
例如，這里應該只有一個Assert ：
```
 Assert.NotNull(result); Assert.IsType<ObjectResult>(result); var objectResult = result as ObjectResult; Assert.NotNull(objectResult); var model = objectResult.Value as InfoMessage; Assert.NotNull(model);
```