业务层与SQL Server

Question

我有一个应用程序，为会员进行复杂计算。每个会员可以将多个美国州与其配置文件相关联。每个课程的每个州都有不同的计算。

目前，我已在数据库（SQL Server 2008）中执行计算，然后将数据发送回应用层，用户可以查看其历史记录，然后下载每个课程的证书。

我有一个业务逻辑层，但那里没有发生太多事情。我知道这个问题被问了很多次，但是您认为我应该在哪里执行这些计算：业务层或数据库？我来回犹豫！！

- mick

---

如果您的计算需要返回许多数据到中间层，例如进行SUM计算等，我会在数据库中进行计算。何必发送那么多数据呢？数据库非常适合对一些值进行求和，并仅发送回单个结果——效率更高！因此，每当您需要做很多但只返回少量数据时，请在服务器端完成计算。 - marc_s

我同意 @marc_s 的观点，SQL Server 旨在快速高效地处理数据。 - Mark Kram

Answer 1

我基本上会在SQL Server中执行以下操作：

• 大量对数据进行求和、计数、平均值等操作，并仅返回单个值。将大量数据传输到中间层只为了汇总一列真的没有意义

• 大量进行行/集合操作；如果需要复制、插入、更新大量数据，则没有必要将所有这些数据拖到中间层，然后再将其全部发送回服务器-从一开始就在服务器上处理它们。此外：T-SQL在处理集合操作（如数据移动）方面比中间层中的任何内容都要快得多

简而言之：除非您绝对必须这样做（例如，因为您想下载存储在数据库中的文件，或者如果您确实需要将这200行材料化为应用程序中的对象以在某处显示或操作），请尽量避免向客户端/中间层/业务层发送大量数据

一个经常被忽视的功能是在数据库表中的计算列-它们非常适合将订单总额加税和运费计算为总金额，或者它们非常适合将您的名字和姓氏组合成显示名称。这些东西真的不应该仅在业务逻辑层中处理-如果您直接在数据库中处理这些内容，则可以在检查数据库表并查看SQL Server Mgmt Studio中的数据时使用这些“计算”值...

---

如果需要进行广泛的逻辑检查、字符串解析、模式匹配等操作，我会将其放入中间层/业务逻辑层

• 如果需要调用Web服务以获取某些数据来验证您的数据，或类似的操作

• 如果需要更多的业务逻辑操作（而不是严格的“原子”数据库操作）

但这些只是“粗略”的指导方针-对于每种情况，这总是一个设计决策，并且我不相信有严格的规则；在不同的情况下，您可能会得到不同的结果-因此，请选择最适合手头任务的方法。

- marc_s

Answer 2

在数据库中（存储过程）内部没有业务逻辑代码有助于提高程序的可读性。更好的方式是将其直接放置在应用程序中，以便与架构完全匹配。这些SQL代码包含了您的业务逻辑，而且没有任何问题。（虽然将数据或维护相关代码放在存储过程中也没有问题）。

如果您的业务逻辑层并没有做太多事情，只是将数据从SQL Server传递给调用者，那么您可能根本不需要它。

- usr

---

存储过程可以非常有帮助，只要它们处理数据库操作而不是“隐藏”业务逻辑。但对于许多操作，拥有存储过程非常有用。我不会全面“禁止”它们。 - marc_s

谢谢大家，基本上，一旦我捕获到所参加课程的数据，我会向每个注册州的成员发送一份报告，其中包括他们所有的学分。我认为数据库是执行这些计算的正确位置。一个纯粹的vb.net/c#人让我想知道我是否做得正确。当然，他认为所有的事情都应该在BLL中完成。每种情况都不同。 - mick

不要死板地遵循 BLL 和 DAL 等“最佳实践”，要有常识。将它们放在工具箱中，在合适的时候使用它们。 - usr

Answer 3

业务逻辑层不是用来承担重任的，它的目的是提供一个抽象层，使用主题语言中的实体。因此，业务层可用于为需要在该空间中工作的任何层/应用程序提供共享和一致的方法。

为了过度设计事物以证明一点，最终目标是业务逻辑层在整个组织中用于在该主题空间中工作的所有应用程序。即封装在服务中等。

在小型应用程序的现实世界中，业务逻辑层有时感觉像是附录。诀窍是还要记住，任何用例都应作为针对业务层的测试实施，从而为您提供另一种思考其公共接口应如何看待的方式。

业务逻辑层如何完成工作应该对调用它的应用程序部分隐藏。

因此，完全可以以最有效的方式（即SQL）计算数据，只要这些计算在业务逻辑层中得到适当的表示即可。

- Nat