6

我有一个为成员进行复杂计算的应用程序。每个成员可以将多个美国州与他们的个人资料相关联。每个州对成员完成的每门课程都有不同的计算。

到目前为止，我一直在数据库（SQL Server 2008）中执行计算，然后将数据发送回应用层，在那里他们可以查看他们的历史记录，然后为每门课程下载证书。

我有一个业务逻辑层，但那里发生的事情并不多。我知道这已经被问了很多，但你认为我应该在哪里执行这些计算：业务层还是数据库？我来回走！！

4

3 回答 3

6

我基本上会在 SQL Server 中做任何事情：

  • 对数据进行大量求和、计数、平均等操作，只返回一个值。将大量数据传输到中间层确实没有意义，只是总结一个列

  • 做了很多基于行/集合的操作；如果您需要复制、插入、更新大量数据，那么将所有数据拖到中间层然后将其全部发送回服务器实际上是没有意义的——从一开始就在服务器上进行。此外：T-SQL 在处理基于集合的操作（如随机播放数据）方面比中间层中的任何操作都要快得多

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

一个经常被忽视的特性是数据库表中的计算列——它们非常擅长将您的订单总额加税和运费汇总到一个总计中，或者它们非常适合将您的名字和姓氏放在显示名称中. 这些事情真的不应该只在业务逻辑层处理——如果你直接在数据库中做这些事情，当你检查数据库表并查看 SQL Server 中的数据时，这些“计算”值也可供你使用管理工作室...

我会把它放到中间层/业务逻辑层

  • 如果它需要大量的逻辑检查、字符串解析、模式匹配等；T-SQL 不擅长这些事情

  • 如果它需要调用 Web 服务来获取一些数据来验证您的数据，或者类似的东西

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

但这些只是“粗略”的指导方针——它始终是每个案例的设计决定，我不相信严格的规则；您的里程可能会因情况而异 - 因此请选择最适合手头任何给定任务的方法。

于 2012-01-24T21:42:37.643 回答
0

它有助于在数据库（存储过程）中没有业务逻辑代码。将它直接放在应用程序中会更好，这样它就适合架构。此 SQL 代码包含您的业务逻辑，它没有任何问题。（尽管在存储过程中拥有数据或维护相关代码并没有错）。

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

于 2012-01-24T21:48:31.557 回答
0

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

为了说明问题，最终目标是在整个组织中为在该主题空间中工作的所有应用程序使用业务逻辑层。即包裹在服务等中。

在小型应用程序的现实世界中，业务逻辑层有时确实像一个附录。诀窍是还要记住，任何用例都应该作为针对业务层的测试来实现，让您以另一种方式来思考它的公共接口应该是什么样子。

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

因此，以最有效的方式（即 sql）计算数据是完全可以接受的，只要这些计算在业务逻辑层中给出了适当的表示。

于 2012-01-24T21:56:21.230 回答