現在，我已經開始在3層架構工作，但我已經在我的心中有一個疑團。3層架構問題
一般來說，我們的數據控件綁定到一個ObjectDataSource控件，並調用業務對象的功能進行選擇，插入，更新或刪除操作。這種方式我沒有任何問題。
但是，我的問題是，我有一個登錄部分，只包含2個文本框和1個按鈕，我創建了一個業務對象，其屬性代表用戶名和密碼，然後我調用業務對象的功能，該功能依次稱爲數據訪問層函數返回從數據庫中包含一個用戶ID數據行，如果用戶名和密碼是正確的....
，所以我認爲這是不與3層的工作，當你不使用數據控件工作的正確方法......因爲在這裏我們無理調用功能和功能的同時，我們甚至可以在後面的代碼中訪問數據......所以請告訴我，我是否正確或不工作？......還是有進行同樣的操作中沒有更好的辦法。
ASP.NET是奇數，當涉及到數據和業務邏輯的分離。 MVC使它更容易，但你不指定是否使用它。我們解決這個問題如下：
我們構建了一個靜態的序列化類，它負責與數據庫交互。它本身負責調用存儲過程。它返回序列化器知道如何實例化和用數據庫中的數據填充的POCO實例（普通的舊C＃對象）。
現在，波蘇斯提供轉發到串行電話門面方法。例如：
public static Employee Load(int id)
將調用EmployeeSerializer類的Load方法。它不會做別的。但它可以讓頁面以自然的方式與Employee對象一起工作。
可能不適合，但它比我們以前更好。同樣，您調用Employee.Save（），並將調用轉發給EmployeeSerializer。
這使所有封裝在一個類中調用存儲過程。業務邏輯封裝在Employee類中。並且頁面可以與Employees一起工作。
注意，業務對象可以住在從數據庫對象的一個單獨的DLL，但是這往往導致循環依賴。將它們保存在同一個DLL中，並將它們放在不同的名稱空間中。但是通過將它們放在一個單獨的DLL 中，可以將它們與ASP.NET頁面分開。
那就是懶惰的程序員在你說話。
三層是絕對的。你不能有三分法。這不是三層。
3層有使代碼從長遠來看更容易維護，不能減少時間短千卡發展。使用層級盧克。