Web API /業務邏輯層架構

Question

我想獲得關於我上週繼承的應用程序結構的一些反饋，以及關於如何最好地重組它的建議。雖然我不是說我會更好吧:)

這裏是它的本質我沒有名字什麼：

的紅項目有4個類庫：

1. UI - .NET Web窗體。這是一個門戶網站，顯示有關您的銷售和工作時間表的信息，以及來自位於其他地方的API的產品信息。
2. WebApiControllers - WebAPI控制器列表。他們返回列表<產品>（最終得到序列化）。它們主要由另一個名爲Blue的項目使用。
3. WebService - 其唯一工作是查詢位於美國另一地區其他地方的私有API並返回產品信息等JSON表示。
4. 域名 - 從我所知道的情況來看，這似乎有兩件事情正在進行。首先它直接調用＃3（webservice）將數據重新獲取爲json，然後將其反序列化爲相應的對象。其次是它包含了反序列化的類本身，以及用於＃2的數據傳輸對象。

-

的藍項目有1個類庫： 的ASPX形式與阿賈克斯的列表調用指向紅色項目WebApiControllers（＃2以上以上）

-

問題

似乎在歷史上一直在紅色項目將如何GR一些混亂時間流逝以及它是如何設計的。由於Red使用Web表單，因此需要提供很多來自私有產品API的數據。結果我看到了以下回吐地方：

1. 有些人從WebApiControllers層實例化控制器，然後調用他們的方法直接取回對象。這正好發生在Web表單代碼中。

2. 其他人直接調用webservice層，但它不是很容易，有一些東西，如請求標頭，語言，用戶標識和其他「雜亂」細節，每次請求時都需要訪問或實例化。

我正在考慮製作一個門面到web服務層，然後指示每個人通過門面訪問API。唯一的問題是我會重複已經在WebAPIController類庫中完成的所有事情（因爲這有30個方法，所以我必須在這個新層上的幾個不同的外觀或服務中分割這30個方法）。我不知道這是否真的有問題，但是想把它拋出去，看看你們都在想什麼。然後我會告訴人們，他們不應該實例化控制器，而是使用正面或應用程序服務層。

你們都在想什麼？

謝謝！

Answer 1

一個門面可以工作，但正如你所提到的那樣，構建（並維護）它可能是一件大事。如果問題是以標準方式設置HTTP請求，也許您可​​以提供一種實用方法來發送HTTP請求？類似：

public dynamic SendWebApiRequest(string url, IDictionary<string, string> parameters)

的方法，隨後將照顧設立HttpClient，執行請求，並返回結果的。只是一個想法...