我是新來的設計模式。我想學習構建3層架構。我曾經在一些地方進行過搜索但感到困惑。在本文中，http://www.dotnetfunda.com/articles/show/18/4-tier-architecture-in-aspnet-with-csharp編寫者添加了另一個名爲業務對象層的層。據我所知，將數據從一層傳輸到另一層是非常有用的。由於該層只包含業務對象，因此我們可以將此層的引用添加到其他層，並且不會違反規則。創建n層應用程序
但是其他一些文章，他們正在使用DTOs。採用這種方法，我們必須在DAL和BAL之間轉換數據。
我認爲使用業務對象層更加合乎邏輯和容易，我看不出使用它的任何缺點。
請幫我來一個穩定的解決方案。謝謝
因爲您在全局範圍內使用業務對象，所以在整個應用程序中，擁有自己的層將可以工作。因爲業務對象不是特定於實現的，所以它們不應該緊密地耦合到任何外部依賴項。假設您沒有使用像Linq to Sql這樣的數據訪問技術，其中對象需要特定於Sql的代碼。
儘管如此，在過去的幾年中，我已經轉向了「洋蔥建築」設計。我將我的業務對象（實體）和我的接口保存在一個核心項目中。我將所有業務代碼和特定於實現的代碼添加到服務項目中，最後添加標準UI項目。 UI和服務項目都只知道核心。我的所有服務都實現了核心中的一個接口，我的UI代碼是針對核心接口編寫的，而不是具體的服務實現。通過這種方式，我的用戶界面和我的服務完全分離，彼此不知情。這種模式也可以擴展到包括其他項目（我使用的基礎設施橫切關注，如日誌記錄）。
不過，對於n層方法，我認爲業務對象層沒問題。您也可以將某種本地數據記錄（C＃中的DataTable等）返回到您的業務層，將對象保留在那裏，幷包含一個接受本機數據類型的構造函數。