我的数据访问层应该返回Person还是Datatable？

Question

阅读完这个之后，我还有一个问题:

我使用以下代码来查询数据库：

c# :

new BLL().GetPersonById(1)

BLL :

public Person GetPersonById(int id)
{
  return new DAL ().GetPersonById(1);
}

DAL :

public Person  GetPersonById(int id)
{
   // goto db and create instance of Person and fill its data...
}

然而，我做错了吗？

我的数据访问层(DAL)应该返回DataTable而不是Person对象吗？这样业务逻辑层(BLL)就会创建Person对象...?

DAL：

public DataTable  GetPersonById(int id)
{
   // goto db ...
}

谢谢。

编辑：

Person对象定义在BE dll（业务实体）中。

- Royi Namir

---

在你的BLL中返回任何你需要的内容。你的DAL是否完全了解“Person”？ - Tim Schmelter

@TimSchmelter 嗨Tim，不过我想知道将我的数据访问层（DAL）引用到业务实体层（BE）是否是一件坏事，因为业务逻辑层（BLL）已经引用了它... - Royi Namir

@TimSchmelter 是的，它有一个对BE（实体）的引用。 - Royi Namir

个人而言，如果我看到DataTable被使用，除非有一些非常好的原因（主要是：如果架构完全不可预测），否则我会认为存在非常大的问题...应该使用Person！但是：这里没有单一的答案，只是个人观点。 - Marc Gravell

你的BE项目中具体包含什么？接口？业务对象本身？如果是这种情况，那么BLL中有什么？也许你的业务实体实际上是ORM实体？ - MikeSW

Answer 1

"我的DAL应该返回DataTable吗？（这样BLL就可以创建Person....?）" 绝不是。理想情况下，DAL应该处理数据库，并将实体/应用程序对象返回给BAL。 DAL作为BLL的数据库抽象层工作。 我同意MikeSW的看法，他说“BLL不应依赖于DAL，最多只定义一些接口，这些接口将在DAL中实现”。

- Praveen Prajapati

---

为什么数据访问层（DAL）应该引用业务实体（BE）？业务逻辑层（BLL）从DAL中的datatable创建Person有什么问题吗？ - Royi Namir

创建层之前，我们应该了解一些基本概念。不同的层用于分配应用程序的职责。例如，在 BLL 从 DLL 中获取 Datatable 的情况下，如果数据库发生更改，则需要同时更改 DLL 和 BLL 中的逻辑。这并不好。否则，您只需要更改 DLL。这只是为什么 BLL 应该仅获取实体/应用程序对象的一个示例。还有其他方面，如可维护性、清晰的工作流设计、最小化更改和副作用等。 - Praveen Prajapati

PraveenPrajapati + @mike 你能去这个链接吗 http://chat.stackoverflow.com/rooms/19201/room-for-royi-namir-and-mikesw - Royi Namir

Answer 2

你的DAL，确切地说是Repository，返回的是BLL中定义的Person业务对象。

BLL不应依赖于DAL，最多只定义一些接口，这些接口将在DAL中实现。然而，应用程序会向DAL请求存储的业务对象，因为它的职责是处理所有持久性相关的事情。

是的，DAL依赖于BLL。DAL应该仅返回应用程序对象（业务对象或视图模型），隐藏所有与持久性访问相关的内容。

- MikeSW

---

Person对象定义在BE中而不是BLL中。 - Royi Namir

@MikeSW 我的理解是，DAL 绝对不应该知道 BLL 的存在，而 BLL 只应该知道 DAL 的接口。但是，它们都应该知道共享对象定义（例如在这种情况下的 Person）。我错了吗？ - neeKo

这取决于应用程序的大小。在最高层面上，是的，您将拥有一个仅包含接口的公共层，然后BL和DAL将实现它们，而彼此之间则互不知晓，但如果您实际上不需要它，那么这可能会过度设计。 - MikeSW