c# - 从数据访问层提取业务逻辑

Question

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

因此，到目前为止，我觉得我正在为 2 个角色使用数据访问层:业务层和数据访问层。

我无法决定必须将哪些内容移至单独的图层以及是否需要。我在某处读到，知道何时进行层分离是智慧，而了解模式只是知识。我的数量都不够。

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

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

GetProductAvailabilitybyItem

GetProductAvailabilitybyLot

等等

如果我需要将它们分开，我必须做什么？

我脑子里的另一件事是，为了规范化我的 DAL 并让它每次都返回不同的实体(通过一种通用的 get 方法)，我将不得不使用 DataTable作为返回类型。目前我正在使用类似 List<PalletRecord> 的东西作为返回类型。

我觉得我的应用太小了，很难(而且可能没用)区分这两层。

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

附加示例:

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

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

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

Answer 1

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

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

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