从数据访问层拉出业务逻辑答案

【问题标题】：Pulling out business logic from the data access layer从数据访问层拉出业务逻辑
【发布时间】：2012-11-26 16:32:34
【问题描述】：

我们正在为我们的 ERP 系统编写一些支持应用程序（相当小的）。

因此，直到现在我觉得我将数据访问层用于 2 个角色：业务层和数据访问层。

我无法决定必须将哪些内容移至单独的图层以及是否需要。我在某处读过，知道何时进行分层是智慧，知道模式只是知识。我没有足够的量。

所以我需要一些帮助来确定什么是什么。

我当前的 DAL 处理获取数据并在其上应用基本逻辑。例如有像

这样的方法

GetProductAvailabilitybyItem

GetProductAvailabilitybyLot

等等

如果我需要将它们分开我该怎么办？

我脑海中的另一件事是，为了规范化我的 DAL 并使其每次都返回不同的实体（通过一个通用的 get 方法），我必须使用 DataTable 作为返回类型。目前我使用List<PalletRecord> 之类的东西作为返回类型。

我觉得我的应用程序太小了，很难（而且可能没用）区分这 2 层。

我的基本需求是构建可以被多个前端（网页、WinForms、WPF 等）使用的东西。

其他示例：

让我们谈谈一些条形码。我需要检查提取的批次记录是否有效。我正在获取 DAL 中的记录并在业务层中生成返回 bool 的方法？

然后我可以从任何演示文稿中调用 bool 方法来检查文本框是否包含有效的批次？

这逻辑是不是极其简化了？

【问题讨论】：

【解决方案1】：

根据您的描述，当应用程序还很小的时候，您现在绝对应该将两层分开。当您只是访问和显示数据时，您可能会觉得 BL 没用，但随着时间的推移，您会发现需要修改、转换或操作数据，例如从不同的表创建坐标对象，或更新一个来自用户的单个操作。

您提供的示例有助于支持这一想法，尽管非常简化。

Pablo 的回答也确实提供了一些很好的设计理念：您绝对应该使用 ORM 来简化您的 DAL 并使其非常精简。我发现NHibernate and Fluent 在这方面做得很好。您可以使用 BL 来协调使用数据访问对象的访问。

【讨论】：

我认为尽早分离是件好事，即使 BL 什么都不做，只是给出结果并接受请求。我相信随着时间的推移我会要求更多。所以说业务决策（如 islotvalid）应该交给 BL 并属于 DAL 是相当不错的，是吗？
是的，您可以有一个非常简单的GetRecord(int id) 方法，然后根据IsValid 属性返回bool。然后，如果您需要检查另一个表来检查Record 是否有效，您不必修改现有的 DAL。

【解决方案2】：

鉴于您正在处理非常小的应用程序，为什么不让 ORM 为您提供所有数据访问，而只需担心业务层？

这样你就不必担心处理DataTable's，将数据映射到对象等等。开发速度更快，并且您可以减少代码库的大小。

现在，如果您要向外部消费者提供数据（您正在实施一项服务），您可能需要创建一组单独的 DTOs 以通过网络传输，而不是尝试发送您的实际模型实体。

【讨论】：

如果我想检查一个非常小的应用程序的 ORM，我可以在一个 DAL dll 中使用传统的手动编码（oledb 连接、阅读器等）方法和 ORM 方法吗？
@e4rthdog 你可以，虽然它可能会变得非常混乱，非常快。为什么需要手动处理连接或读取器？
因为我已经准备好了一些东西，需要完成它......但我想当我开始时，我会明白以一种方式做它更好......谢谢
你可以，我只是不确定你会从中获得多少。如今，ORM 的性能非常好。请注意，ORM 将管理其数据库连接，如果您将手动执行操作，则需要考虑这将如何影响正在进行的事务以及类似的事情。

【解决方案3】：

我不是 nTire 架构的忠实拥护者，并且有一些很好的理由。

这种架构的主要目标是

但是，在这样做的同时，您也会做出一些牺牲，例如放弃特定于提供商的优化等。

我的建议是，您可以采用两层架构，即数据访问和业务逻辑层和 GUI 或表示层。它仍然可以让您拥有适用于不同平台的通用代码，同时让您免于使用意大利面条式代码。

【讨论】：