WCF /客戶端應用程序 - 業務邏輯應該去哪裏？

Question

我們正在使用WSSF構建WCF Web服務。這個想法是，它會通過服務暴露我們的主數據庫，並允許我們在服務之上構建各種應用程序和網站。目前，我正在構建一個簡單的客戶端應用程序，該應用程序將從該服務下載一些數據，對其進行處理，然後將其作爲報告CSV文件提供給用戶。

現在的問題是業務邏輯（操縱數據）應該放在哪裏？我想我會把它放在服務裏面。我已經有了一個業務層，其中包含幾乎與數據庫一一對應的簡單對象（客戶，訂單等）。我認爲我會製作一些「更高級別」的對象來操縱數據。例如，通過使用客戶，訂單和其他對象並生成報告等。我認爲最好的地方在於服務的業務層。這樣，如果需要，我們可以將這個邏輯用於各種不同的應用程序。

不幸的是，我的老闆不同意。他希望有一個「關注點分離」，並說這個邏輯的正確位置應該位於客戶端應用程序內的業務層，而不是服務中。我想這可能會更簡單，但我想在服務業務層中使用強大的對象模型編寫此代碼。服務公開的對象不是「真實」的對象，實際上只是輕量級的數據結構，沒有服務業務層中存在的完整對象模型的能力。

你們認爲什麼？非常感謝您的幫助。

乾杯 馬克

Answer 1

我認爲什麼是「正確的」取決於你的應用程序體系結構。分離關注確實是有價值的。這聽起來像你的老闆認爲當前的模型是使用服務器作爲數據訪問層，將數據庫映射到業務對象，業務邏輯應該在客戶端上實現。

無論業務邏輯是在客戶端還是服務器上實現，您仍然可以分離關注點。這不是你處理重要的地方，而是你設計應用程序層之間接口的方式。

這可能有助於更多地瞭解客戶。你在處理瀏覽器/ Javascript客戶端嗎？如果是這樣，那麼我會盡可能在服務器上進行儘可能多的處理，並以您希望顯示的形式或多或少地向客戶端發送數據。

如果它是一個C＃客戶端，那麼在這方面你有更多的權力來處理。您可能可以將WCF服務的響應重構爲您在服務器端使用的相同業務對象類，並獲得與服務器上相同的權力。 （只是在兩個解決方案之間共享業務對象類）。

Answer 2

對此沒有硬性規定，但在這種情況下，我會說你的老闆比你更爲錯誤:)每個人都會有一些不同對此的看法，並且可能有多種原因將您的業務邏輯放在業務層以外的其他位置，但很少有理由將其放入客戶端應用程序中 - 您可以爭辯說，當它位於客戶端中時應用程序，那麼它是一個UI或演示規則，而不是業務規則。

如果web服務將被許多應用程序使用，那麼儘可能多的你需要Web服務端的業務邏輯。我實際上有一個非常瘦的webservice層，它所做的只是接受調用，然後將執行傳遞給實際的業務層。我還會在數據庫層中完成數據庫數據和業務數據實體之間的映射，而不是業務層。

Answer 3

我的投票將是明確的：

• 把儘可能多的數據完整性檢查到數據庫
• 放任何其他業務邏輯檢查到業務邏輯層上的服務的服務器端
• 只需將「所需字段」等簡單檢查放入客戶端層，根據數據庫模型或您的商業模式最佳自動確定

爲什麼要數據庫？
任何形狀或形式的SQL都有一些非常基本和非常強大的檢查功能 - 確保東西是唯一的，確保表之間的關係完整性是給定的等等 - USE IT！如果您在數據庫中執行這些檢查，那麼無論您的用戶如何最終連接到您的數據（恐怖場景：管理員能夠使用Excel直接連接到您的表格以執行一些商業智能工作......），那些支票將到位並將執行。強化數據完整性是任何系統的最大要求。

爲什麼服務器上的業務邏輯？
其他答覆者提到的原因相同：集中。您不希望僅在客戶端擁有業務邏輯和支票。如果貴公司的其他部門或第三方外部顧問突然開始使用您的服務，但所有驗證和業務檢查都不到位，因爲他們不知道他們？不是一件好事......

邏輯在客戶端
是的，當然 - 你也想放一些簡單的檢查到客戶端，尤其是如果它是一個Web應用程序。像「此字段是必需的」或「此字段的最大長度」等事情應該儘早實施。理想情況下，這將由客戶端從數據庫/服務層自動獲取。 ASP.NET服務器控件具有可以自動打開的客戶端驗證，Silverlight RIA Services可以在後端數據模型中獲取數據限制並將它們傳輸到客戶端層。