4

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

因此，直到现在我觉得我正在使用数据访问层来处理两个角色：业务层和数据访问层。

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

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

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

GetProductAvailabilitybyItem

GetProductAvailabilitybyLot

等等

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

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

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

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

附加示例：

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

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

这是不是非常简化的逻辑？

4

3 回答 3

2

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

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

例如，NHibernate或 Microsoft 的Entity Framework

现在，如果您将向外部消费者提供数据（您正在实施服务），您可能希望创建一组单独的DTO来通过线路，而不是尝试发送您的实际模型实体。

于 2012-12-08T19:42:05.227 回答
2

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

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

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

于 2012-12-08T19:48:57.447 回答
1

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

这种架构的主要目标是

  • 能够与不同的底层数据库分离
  • 上下文——即应用程序设计和业务逻辑的一致性和
  • 确认最佳模式和实践。

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

我的建议是，您可以采用两层架构，即数据访问和业务逻辑层以及 GUI 或表示层。它仍然允许您拥有适用于不同平台的通用代码，同时将您从意大利面条代码中拯救出来。

于 2012-12-08T19:53:08.940 回答