关于为什么我们不应该在几个地方都有业务逻辑,我已经读了很多articles,但是试着把它保存在BLL代码中 . 我理解易于维护的重点,更清楚地了解代码的作用 .
但是,我从未发现任何解释,在将一些业务规则应用(重复)到存储过程会显着减少从数据库到客户端应用程序的数据传输的情况下,我们应该怎么做?
例如,我目前正在进行一些较长时间的一些统计数据表示 . 目前,所有业务逻辑/规则都在商业逻辑层(dll)中 . 用户可以选择在月份级别上显示一年的某些结果 . 这意味着,如果我不在存储过程中使用业务规则,我将需要返回大约1,000,000条记录,然后在客户端将业务规则应用于此记录 . 但是,如果我要将业务规则应用于存储过程,那么它会将返回的记录数减少到12 .
应用业务规则的示例如下所示:
AVG(CASE WHEN Field1 IS NULL
THEN CASE WHEN c.Field2 = 1
THEN ( cap1.Field3 / cap1.Field4) * 60
ELSE CASE
..... etc
所以这不是一个简单的逻辑,而是一个复杂的逻辑 . 并且由于这种逻辑可以在许多不同的存储过程中重复,这将成为数据库中单独函数的候选者,以避免重复代码 .
那么,推荐的方式是什么?和 why ?
1 回答
也许你仍然可以拥有它所属的业务逻辑,并将这些东西归类为更多的“计算”?
无论哪种方式,当你有一百万行时,你有一个令人信服的理由在数据库层进行计算 . 所以我会把计算保留在函数中 . 因此,在您的示例中,将使用可重用函数,如:
或者如果它被大量使用,足够简单并且仅取决于单行中的列,则表中的计算列将更方便 .
您的函数dbo.fnFieldsEvaluat(或计算列)将提供计算所在的一个位置 .