三层架构模式

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命名空间。