什么对象应该从数据访问层返回到业务层一个n层系统答案

【问题标题】：What objects should you return from the data access layer to the business layer an n-tier system什么对象应该从数据访问层返回到业务层一个n层系统
【发布时间】：2010-10-05 19:44:46
【问题描述】：

例如，如果您有一个名为 Person（ID、Name 等）的数据库表，那么数据访问层应该将哪种对象返回给业务层？我在想这样的事情：

//data access tier
public class DataAccess{

   public interface IPerson{
      int ID{ get; set; }
      string Name{ get; set; }
   }

   internal class Person : IPerson{
      private int id;
      private string name;

      public int ID{ get{return id; } set{ id=value; } }
      public int Name{ get{retutn name; } set{ name=value; }
   }

   public static IPerson GetPerson(int personId)
   {
      //get person record from db, populate Person object
      return person;  
   }
}

//business tier
public class Person : IPerson{
   private int id;
   private string name;

   public int ID{ get{return id;} set{id=value;} }
   public string Name{ get{return name;} set{name=value;} }

   public void Populate(int personId){
      IPerson temp = DataAccess.GetPerson(personId);
      this.ID = temp.ID;
      this.Name = temp.Name;
   }
}

但这一切似乎有点麻烦？这个问题有更优雅的解决方案吗？我应该将 DataRow 从数据访问层返回到业务层吗？

【问题讨论】：

标签： .net asp.net design-patterns architecture n-tier-architecture

【解决方案1】：

您无需在数据访问层 (DAL) 中重复类定义。

您可以在单独的程序集中将业务实体创建为“哑”容器，例如您的 Person 类可以是：-

public class Person
{
    int ID { get; set: }
    string Name { get; set: }
}

然后，您可以为您的 DAL 提供对业务实体层的引用。您的控制器对象，无论它们是在单独的业务逻辑层中还是在您的 UI 层中，都可以调用 DAL，它可以创建一个业务实体，从数据库中填充它并将其返回给您的控制器。

Imar Spaanjaars 的This article 很好地解释了这种模式。

【讨论】：

不会向 DAL 提供对业务实体层的引用会创建 [不希望的] 双向依赖关系吗？
不，业务实体层将没有对 DAL 的引用。它只是“愚蠢”容器对象的集合。从 DAL 请求它们的应用程序部分（UI 或单独的业务逻辑层）应该在程序集的另一部分中，并且应该引用 DAL 和实体。
程序集 A：类定义，只有字段和属性。域组装。组件 B：DAL。参考程序集 A. 程序集 C：UI。引用程序集 A 和 B。
@yodaj007 - 正确。您还可以引入业务逻辑层 (BLL)，例如 Imar 文章中的“Manager”类。您的“域程序集”等同于 Imar 的业务对象程序集 (BO)。然后参考是：- UI->BO, UI->BLL, BLL->BO, BLL->DAL, DAL->BO.

【解决方案2】：

您的业务层肯定不想了解数据行 - 尝试将数据特定类留在数据层中。这减少了耦合，让您可以在以后更改持久层，而无需大规模重新架构。

要解决您的具体问题，您可以：

在您的数据层中创建基本数据对象/实体，并将它们交给您的业务层以供使用。
或者，就像您正在做的那样，创建 DTO（数据传输对象），其存在纯粹是作为将数据从数据层传输到更高层中更丰富的业务对象实现的一种方式。您可以将此作为富域模型中存储库模式的一部分。

您可能要考虑的另一件事是层 v 层 - 您对这些事情的看法会有所不同。层通常是物理层，换句话说，它们定义了进程之间的边界。层通常是合乎逻辑的，它们将程序的功能分成松散耦合的单元。在这种情况下，您的目标是图层。

【讨论】：

【解决方案3】：

如果您为 DAO 类创建接口并将它们放置在业务层中，则可以从数据访问层引用您的业务层。数据层中的 DAO 类从业务层返回对象。

您的业务层引用接口而不是直接引用数据访问对象。通过 IoC 容器（例如 Castle Windsor）进行依赖注入将允许您完成此操作。

这种技术称为分离接口，在此处进行描述：

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

我所见过的对这种技术的最佳解释可以在这篇关于 NHibernate 最佳实践的文章中找到，由 Billy McCafferty 撰写。

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

这篇文章有很多特定于 NHiberbate 的信息，但其中很大一部分只是关于设计松散耦合和易于单元测试的应用程序的可靠信息。

【讨论】：

【解决方案4】：

由于每个层都必须与上层松散耦合的规则，将 BL 引用添加到 DAL 并不是一个好主意。它更好地在 DAL 中使用接口定义数据模型，并在 BL 中制作业务实体形式。根据我的经验，最好在 DAL 中使用存储库并在您的业务实体或业务流程中访问。

【讨论】：