Question

我正在创建一个允许我创建计划任务的应用程序。我有一个每分钟在后台运行的线程进程，并触发以下类：

Namespace MyName.space
  Public Class RunJob
  ...
  End Class
End Namespace

作业可以是“Run Once”或“Recurring”。

我在vb.net中查询作业表，将结果存储在数据集中，以便我可以一次迭代一次。然后，我开始考虑根据其独特标准验证作业是否应该运行的函数。

例如，最简单的就是“运行一次”作业：

If Type = "Run Once"
    JobShouldRun = Helpers.Validate_RunOnce(WhenToRun, RunCount)
ElseIf Type = "Recurring"
    ...
End If

该函数将检查“WhenToRun”是否在服务器上配置的当前日期和时间的5分钟内。如果任务失败，我选择了一个5分钟的窗口，这样一分钟后它会再次尝试，但仍然会有3-4次尝试。

但后来我开始认为我可以在SQL Query中控制更多这个以获取作业本身，并跳过在vb.net中验证这个“简单”，但我不确定哪种方法会更优化。所以我可以将结果集限制为在我的初始查询中开始：

SELECT
     JobId
    ,JobType -- Run Once or Recurring
    ,WhenToRun

FROM JobTable a
WHERE Active = 1
AND (
      JobType = 'Run Once'
      AND TotalRuns = 0
      AND DATEDIFF(minute, getdate(), a.WhenToRun) BETWEEN 1 AND 5
    )
OR JobType = 'Recurring'

然后我开始思考，我应该使用UNION或JOINS执行所有逻辑，还是对周期性作业执行复杂的WHERE / AND / OR调节？它们变得相当复杂......例如每周和一周中的哪几天，以及什么时间等等。或者在每月的最后一天“Jan | March | Etc”中的每个“int”年。

所以我开始思考这些问题：

SELECT 
     JobID
    ,JobType
    ...
FROM JobTable 
WHERE RecurringType = 'Weekly'
AND ... more conditions based on all the custom job settings

UNION ALL

SELECT
     JobID
    ,...
FROM JobTable 
WHERE RecurringType = 'Monthly'
AND ... more conditions based on all the custom job settings

这个查询最终会变得非常庞大和复杂，但我的问题是，我应该在vb.net或SQL中处理这个问题，还是SQL中的简单内容以及vb.net中更复杂的条件？我不确定这两个方向对性能的影响。

Answer 1

您基本上要问＆＃34;我在哪里为业务逻辑添加代码？在应用程序？还是在数据库中？＆＃34;这可能是一个激烈争论的话题，但考虑这两个选项是明智的。每种方法都有一些权衡，说一种方式是正确的，另一种方式是错误的，似乎有点骑士。

如果您的BL代码在应用程序中，您将获得.Net Framework强大功能的主要好处。我喜欢tsql，但你不能像VB.Net那样用它做多少。如果我可以刻板印象开发人员，我怀疑他们通常会更熟悉.Net代码。对于大多数人来说，它可能比tsql更容易调试。由于.Net代码被编译为程序集，因此它也不可能被更改。

如果您的BL代码在tsql中，您可能会发现性能更好一些。你还从.Net代码中抽象出一些复杂性，并使代码库变得更小（有些人可能认为这是件坏事）。如果存在需要修复的错误，则重新部署存储过程（或用户定义的函数，视图等）通常比重新部署应用程序（特别是涉及多个工作站）更容易。在缺点方面，其他人很容易看到（窃取！）您的代码或对其进行更改。

作为一般指导原则，业务逻辑越复杂，我就越有可能将其放入应用程序中。如果它非常简单且不太可能改变，我会考虑将它放在tsql中。话虽这么说，如果我必须选择其中一个，没有例外，我会把BL放在应用程序中。

在哪里放置业务逻辑？在VB.Net？还是在SQL？

1 个答案: