c# - 直接将数据访问层的值接受到数据合约中是否正确？

Question

我有一个关于将从数据访问层的数据库获取的值分配给 WCF 层的数据协定的正确方法的问题。

考虑一个简单的场景，从数据库中获取所有学生的列表，然后将其分配给学生数据合约。

我的学生数据契约(Contract)如下所示:

[DataContract]
public class StudentDC
{

    [DataMember]
    public int StudentID { get; set; }

    [DataMember]
    public string StudentName { get; set; }
}

在我的数据访问类中，我会有一个类似 List GetAllStudents() 的方法

我的问题是关于 GetAllStudents() 方法的实现。看起来像下面这样可以吗:

1. 公共(public)列表 GetAllStudents() {

   List<StudentDC> studentDCs = new List<StudentDC>();
   
   var students = db.Students_TB.Select(s => s).ToList();
   
   foreach(Student_TB student in students)
   {
       StudentDC studentDC = new StudentDC();
       studentDC.StudentID = student.StudentID;
       studentDC.StudentName = student.StudentName;
       studentDCs.Add(studentDC);
   }
   
   return studentDCs;
   

   }

上述为数据契约赋值的方式是否正确，或者我应该让学生业务对象类在数据访问层中接受数据，然后将值传递给服务契约实现中的数据契约，像下面这样:

1. 我会有如下的学生业务对象类:

   公开课StudentBO {

   int studentID;
   string studentName;
   
   public int StudentID
   {
       get { return studentID; }
       set { studentID = value; }
   }
   
   public <return type> BusinessLogicMethod1()
   {
       // Implementation
   }
   

   }

在数据访问层中，我将从数据库获取的值分配给学生业务对象的集合，如下所示:

public List<StudentBO> GetAllStudents()

{

    List<StudentBO> studentBOs = new List<StudentBO>();

    var students = db.Students_TB.Select(s => s).ToList();

    foreach(Student_TB student in students)

    {
        StudentBO studentBO = new StudentBO();
        studentBO.StudentID = student.StudentID;
        studentBO.StudentName = student.StudentName;
        studentBOs.Add(studentBO);
    }

    return studentBOs;
}

然后，学生业务对象中的值将被分配给服务契约(Contract)实现中的学生数据契约(Contract)，并从那里通过网络发送出去。

以上两种方式哪一种是正确的方式？

Answer 1

首先，您应该询问您的设计目标如下:

• 您的数据库层对象更改的频率(例如添加/更新/删除 新字段)？
• 数据层表更改的频率(重新设计关系、表 结构)？
• 您的 WCF 域对象更改以满足业务/UI 的频率 要求？

将数据层与业务对象分离的主要思想是在它们之间具有一定程度的抽象。因此，持久层(又名:数据访问层)的更改不会对更高级别的业务逻辑产生重大链式 react 。业务逻辑也是如此...如果对其进行更改...对持久层的更改是最小的。

另一个方面是代码的可测试性。您可以为业务逻辑创建单元测试用例并运行它们，而无需将持久层连接到实际数据库。相反，您可以在持久层中使用“模拟”类，以便可以在内存中运行所有内容并在不连接到数据库的情况下测试业务层。

最后，如果您不希望在应用程序的整个生命周期中对任一层进行更改，并且不希望对代码进行维护，那么您可以选择它。 但在大多数情况下，应用程序会发生变化，维护成本是关键点之一......层松散耦合在这里有很大帮助。

您还可以考虑使用 AutoMapper 来外部化数据访问层和业务层对象之间的映射。