三層架構模式

Question

這樣可以使用部分類實現BLL和DAL嗎：

 namespace BLL
{
   partial class Employee
  {
    public string EmpID { get; set; }
    public string EmpName { get; set; }

     public List<Employee> GetListOfEmployees()
     { 
       return DAL.Employee.GetListOfEmplyee();
      }

     }
  }

namespace DAL
{
 partial class Employee
 {
    public static List<Employee> GetListOfEmployees()
    {
        //DATA ACCESS
        var emps = GetEmployeesFromDb(); // fetch from db
        return emps;
   }
 }
}

或其他建議？ 提前致謝。

Answer 1

目前尚不清楚您要通過使類成為partial來實現什么。 當您需要將一個類拆分為多個文件時，部分類很有用-通常是因為一個或多個部分是機器生成的。 在這種情況下，將機器生成的部分與人工編輯的部分分開是非常有用的，可以避免一組更改覆蓋或破壞另一組更改。

在您的示例中，使用partial並不會取得太大效果，因為兩個Employee類位於不同的命名空間中-它們不會合並到單個實現中。

也許，如果您可以解釋您要解決的問題，則可能會更好地回答您的問題。

Answer 2

很大程度上取決於偏好，但是就個人而言，我會為Employee / EmployeeCollection創建創建Factory類，而不是將其放在對象本身中。 如果確實將它放在對象中，則可以使對象創建方法靜態化，因此您不必實例化虛擬對象即可創建真實對象。

過去，我已經將創建邏輯（包括DAL調用）構建到了實際的構造函數中（使用依賴注入將數據配置放入對象中）。 在這種情況下，構造函數采用Id或Name東西-用於標識對象的東西。 它將其傳遞給DAL，並根據結果集構建對象。

Answer 3

您不能以這種方式使用部分類-BLL.Employee與DAL.Employee是不同的類，因為它們位於不同的命名空間中。 您將只有2個局部類，而沒有其他部分。

即使它們確實表示相同的類，也不能同時定義具有相同簽名的方法。

Answer 4

如果我錯了，請糾正我，但是通過在兩個不同的命名空間（DAL和BLL）中創建部分Employee類，您只需創建兩個不同的類。 看起來您想創建一個包含兩個部分類的單個類-在您的示例中情況並非如此。 在您的代碼示例中，您可以簡單地刪除部分標識符。

除此之外，我認為這是從用戶界面和數據訪問中分離業務邏輯的好方法。 因此，可以在同一Visual Studio項目中使用三個程序集或僅使用三個文件夾。 最終，最終取決於解決方案的復雜程度。

特別是當使用LINQ to SQL或Entities時，我發現在數據訪問層中保留盡可能多的LINQ代碼是一種很好的做法。 這將使代碼更加可重用和可測試。

Answer 5

每個其他人都是正確的，因為這會創建兩個單獨的類。 為了不創建兩個單獨的類並通過局部類將數據與邏輯分開，您的項目中可以包含以下兩個文件：

• Employee.cs
• Employee.bl.cs

然后，您的Employee.cs代碼將如下所示：

namespace YourNamespace
{
    partial class Employee
    {
        public string EmpID { get; set; }
        public string EmpName { get; set; }
    }
}

Employee.bl.cs看起來像這樣：

namespace YourNamespace
{
    partial class Employee
    {
        public static List<Employee> GetListOfEmployees()
        {
            //DATA ACCESS
            var emps = GetEmployeesFromDb(); // fetch from db
            return emps;
        }
    }        
}

盡管我認為擁有一個用於檢索數據的Repository GetListOfEmployees在Employee內部擁有GetListOfEmployees更合適。

更新：

當我說存儲庫時，我指的是“ 存儲庫設計模式” 。 存儲庫是用於檢索和存儲對象的接口（例如，從關系數據庫中）。 如果您使用的是諸如LINQ to SQL或ADO.NET實體框架之類的ORM，它們通常會自動生成充當該角色的類。 但是，如果您編寫自己的數據庫訪問代碼，則可以這樣創建自己的存儲庫類：

public class Repository
{
    public Repository(string connectionString)
    {
        // ...
    }

    public IEnumerable<Employee> GetEmployees()
    {
        return GetEmployeesFromDb();
    }

    public Employee GetEmployeeById(Guid id)
    {
        // ...
    }

    public void StoreEmployee(Employee employee)
    {
        // ...
    }

    // etc.
}

這樣做的好處是您不必在整個Employee類或任何其他持久性類中放置數據庫代碼。 所有數據庫訪問都是通過一個界面完成的。 您還可以創建一個interface並具有存儲庫的多個實現。 這樣，您可以將Employee實例存儲在文件中，例如，而不必更改Employee類。

Answer 6

（1）將您的業務對象/表實體放在共享的特定位置。 假設您具有以下類：Employee（可能引用表Employees中的一行），Department（可能引用表Departments中的一行）等等。這些類可能在您的所有層中使用。 因此，請將它們放在帶有命名文件夾的共享位置。

（2）不要將業務邏輯/數據邏輯放在實體中。 您會看到將GetListOfEmployees放入Employee 。 但是實際上它們之間幾乎沒有關系。 應該有一個名為EmployeeManager的類，其中有對員工的操作，例如查找，更新和刪除。

（3）請參閱BLL和DAL中的GetListOfEmployees方法，它們完全相同！ 但是BLL中的方法應該包含“業務邏輯”，因此我們將其稱為BL-Layer。 在BLL方法中，名稱被認為是“商務詞匯”，例如，在方法中，它告訴DAL“我需要所有員工，按名稱排序”。 BLL告訴“我需要什么”，DAL進行挑選。 DAL中的方法沒有任何事務。

Answer 7

可能會逃避OP的一件事是，名稱空間只是執行某種名稱處理的一種幻想方法。 你可以認為BLL.Employee將解析為編譯型的BLL_Employee ，而且DAL.Employee將解析為編譯型的DAL_Employee 。 （這不是真正發生的事情，但是適合我的說明目的。）

當運行時比較類型時，很明顯BLL_Employee != DAL_Employee 。 結果，將DAL.Employee聲明為局部類是沒有意義的，因為沒有其他DAL_Employee可以選擇松弛部分並提供其余的實現。

您要做的是在同一個命名空間中創建兩個文件。

// Employee.cs (In a BLL folder)
namespace BLL
{
    public class Employee
    {
        // Custom business logic.
    }
}

// Employee.cs (In the DAL folder)
namespace DAL
{
    public class Employee
    {
        // Custom data access code here. 
        // Not overwritten by code generator
    }
}

// Employee.designer.cs (In the DAL folder)
namespace DAL
{
    public partial class Employee
    {
        // Generated code goes here.
        // Frequently updated by code generation tools.
        // Do not manually update this code.
    }
}

此外，您不想將業務邏輯與數據訪問邏輯混合在一起，這聽起來像是將BLL和DAL名稱空間中的類合並的目標。 大不行 將它們分開。 您可以考慮引入您調用的第三組類，它們隱藏了DAL名稱空間中的數據訪問類，並僅從BLL名稱空間中返回了合適的業務對象。 這樣，您的DAL命名空間就不必知道BLL命名空間，而BLL命名空間也不必知道DAL命名空間。