ASP.NET三層/三層體系結構 - 如何分離UI和BLL

我目前正在學習計算機科學學位的最後一年，並且正在研究我的最終項目和論文。我將使用ASP.NET Web Forms和C＃創建一個3層項目 - 我無法真正稱它爲3層，因爲它很可能永遠不會被託管在除本地PC之外的其他任何位置，因爲它用於測試唯一的目的。ASP.NET三層/三層體系結構 - 如何分離UI和BLL

我的主要問題是：

從我的理解，3層的想法是，BLL引用DAL和UI引用BLL創建的擔憂完全分離。不過，我已經在幾個教程之後做了一個小模擬項目，以便獲得3層教程，而大多數基本教程仍然需要UI和BLL之間的參考。

例如，在我創建的項目中，這是一個非常基本的產品和類別類型電子商務系統，我在DAL中創建了Product和ProductDAL類，然後在BLL中創建了ProductBLL類。使用這種設置，只使用一個數據庫表（現在忘記類別），BLL似乎只是作爲UI和DAL之間的一種接口，這些方法與DAL中的方法完全相同，只調用DAL版。

問題是，要通過BLL訪問DAL，我必須將Product對象傳遞給BLL方法參數，這意味着首先在UI中創建一個Product對象，這意味着從UI引用DAL。這是做事的正確方法嗎？

我可以通過在BLL中創建一個採用相應字段的方法來解決這樣的簡單情況，例如，字符串和整數以創建產品對象並將其返回給AddProduct方法。但是，當將不同的產品屬性綁定到UI中的標籤時，我仍然需要訪問產品對象。

所以基本上，我是否需要在BLL中加載一些方法來訪問產品對象的屬性？如果不是，那麼實際上會有什麼樣的方法，你能給我一些在這種產品方案中可能會出現在BLL中的方法的例子嗎？

在此先感謝，並表示道歉，如果這已被問及以前 - 我讀了很多關於3層架構的帖子，但大多數都是非常基本的，只能訪問一張表。

來源

2012-10-28 Stu Ratcliffe

的BLL似乎只能作爲一種用戶界面和DAL

這僅僅是因爲這個應用程序是非常簡單的界面 - 只是此刻CRUD接口。更復雜的應用程序有業務規則將被封裝在BLL中（而不是在UI或DAL中）。

我必須將Product對象傳遞給BLL方法參數，這意味着首先在UI中創建一個Product對象，這意味着從UI引用DAL。這是做事的正確方法嗎？

好了，這裏還有幾種不同的選擇：

你可以有一個Product數據訪問對象（DAO）是共享不同層之間。該對象不是DAL對象，但DAL使用它。它被稱爲DTO - 數據傳輸對象。
您可以擁有多個不同的Product對象 - 一個由UI使用，一個由BLL使用，另一個由DAL使用，並具有映射層以在不同對象之間進行轉換。
以上的一些組合。

來源

2012-10-28 11:55:34 Oded

這個答案已經解決了我想要做的大部分要點，但我只是補充一點，你的問題中的混淆可能來自於你似乎認爲「數據訪問層」（例如：ProductDAL）和「數據模型」（例如產品）是相同的。他們通常沒有。 DAL是負責填充模型的代碼，並且模型可以很好地在各層之間共享，就像Oded上面解釋的甚至是不同的（想想DTO的/ ViewModel的等等） – InSane

分離問題的常見方法是首先創建一個名爲YourProject.Entities或類似項目的項目。這包含主類定義，當您需要獲取像客戶或產品之類的大型實體時，可以參考它。除此之外，您還有另一個項目作爲存儲庫。根據您使用的技術，可以實現類似EF這樣的功能，從數據庫獲取對象，也可以包含直接使用SQL或存儲過程直接查詢數據庫的方法。

你必須記住的是，這些項目主要是基於用戶輸入功能。您的用戶將採取行動，您的計劃將作出迴應。這個想法雖然是實際的業務邏輯是從你的用戶界面和你的數據訪問分開。您可以根據需要混合和匹配這些想法，但我在專業經驗中傾向於看到的是在數據庫的數據庫訪問端執行的基本數據約束實施，並且在實體項目中創建對象時直接完成數據驗證或者在一個單獨的EntitiesValidation項目中使用實體作爲參數。

如果您不想擁有單獨的驗證項目，需要記住的一點是您可以使用構造函數和屬性直接在對象中實現業務邏輯。構造函數可以創建對象，並使用全屬性之前，實施對輸入邏輯 - 也就是說這...

private string myProp  

public string MyProp 
{ 
    get 
    { 
     // Some code 
    } 
    set 
    { 
     // Some code 
    } 
}

，而不是這個......

public string MyProp { get; set; }

允許您實現規則時訪問與這些屬性相關的數據。

最後，這些問題可以通過多種不同的方式回答，我相信對這個問題的每一個回答都會給你提供不同的想法和意見，讓你知道如何做最好的事情。對我而言，我始終遵循的兩條規則是DRY（不要重複自己）和代碼可維護性。通過從用戶界面的對象設計中將數據訪問與邏輯分開，您可以更輕鬆地維護和更新程序，即使這只是一個學校項目;）。

來源

2012-10-28 11:59:29

ASP.NET三層/三層體系結構 - 如何分離UI和BLL

回答

相關問題