从数据访问层中分离业务逻辑

Question

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

因此，到目前为止，我感觉我正在使用数据访问层来扮演两个角色：业务层和数据访问层。

我很难决定我需要将什么移动到单独的层中以及是否需要。我曾经在某处读到过，知道何时进行层分离是智慧，而知道模式只是知识。我都不够了解。

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

我的当前DAL处理获取数据并对其应用基本逻辑。例如，有像“按项目获取产品可用性”和“按批次获取产品可用性”之类的方法。

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

我头脑中的另一个问题是，为了规范化我的DAL并使其每次返回不同的实体（通过一个通用的get方法），我必须使用DataTable作为返回类型。目前，我使用像List 这样的返回类型。

我觉得我的应用程序非常小，很难（也许是无用的）区分这两个层。

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

额外的例子：

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

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

这个逻辑是不是非常简单？

- e4rthdog

Answer 1

考虑到您正在处理非常小的应用程序，为什么不让ORM为您提供所有数据访问，并只关注业务层呢？

这样，您就不必担心处理DataTable、将数据映射到对象等问题。开发速度更快，代码库的大小也会减少。

例如，NHibernate或Microsoft的Entity Framework。

现在，如果您将向外部使用者提供数据（您正在实现一个服务），则可能需要创建一个单独的DTO集合，通过网络传输，而不是尝试发送实际的模型实体。

- Pablo Romeo

---

如果我想为一个非常小的应用程序检查ORM，是否可以将传统手写（oledb连接，读取器等）方法与ORM方法全部放在一个DAL dll中？ - e4rthdog

@e4rthdog，虽然你可以这样做，但可能会变得非常混乱，非常快。为什么需要手动处理连接或读取器呢？ - rae1

因为我已经有一些准备好的东西需要完成......但是我猜当我开始的时候，我会明白用一种方法来做更好....谢谢。 - e4rthdog

你可以这样做，但我不确定你能从中获得多少好处。ORM现在的性能非常好。只需注意ORM将管理其数据库连接，如果您将手动执行操作，则需要考虑它如何影响正在进行的事务等方面。 - Pablo Romeo

Answer 2

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

您提供的例子支持了这个想法，尽管它相当简化。

Pablo的答案也提供了一些很好的设计思路：您应该使用ORM来简化您的数据访问层，并使其非常薄。我发现NHibernate and Fluent在这方面做得非常好。您可以使用业务逻辑层来协调使用数据访问对象进行访问。

- rae1

---

我认为即使BL仅提供结果并处理请求，早期分离也是有益的。我相信随着时间的推移，我会要求更多。因此，将业务决策（如islotvalid）交给BL，并将其归属于DAL是可以接受的，对吧？ - e4rthdog

是的，你可以有一个非常简单的GetRecord(int id)方法，然后根据IsValid属性返回bool。然后，如果您需要检查另一个表来检查记录是否有效，则无需修改现有的DAL。 - rae1

Answer 3

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

这种架构的主要目标是：

• 能够处理不同底层数据库的分离 - 即应用程序设计和业务逻辑的统一性和最佳模式和实践的确认。

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

我的建议是，您可以采用两层架构，即数据访问和业务逻辑层以及GUI或表示层。 它仍然允许您在不同平台上拥有公共代码，同时还可以避免Spaghetti代码。

- Murtuza Kabul