问调用ASP.NET Web的存储过程

EN

我在以这种方式使用CLR程序集的地方工作过。在我看来，这是个坏主意。

这是我的推理。

1:在数据库中嵌入逻辑总是不好的。这是一种“编程哲学”的立场，但我觉得这是有道理的。

2: CLR仅限于mssql server上的.net 2。

3: CLR可能由于其对外部资源的依赖而超时或出错。这将产生与sproc不同的结果集。

4: DB选择？然后调用API (然后插入)将给您带来锁定和事务问题，而不是简单的解决方案。

5:您的解决方案中已经有了一个.Net层( webapi)，因此您有了支持windows服务或类似应用程序的基础设施，这些应用程序可以完成业务角色。

我想，你的问题中缺少的东西，使我能够得到一个更好的模式，是什么叫sproc在第一？

就像我所知道的那样，在第一点上做一个快速的扩展是有争议的。我在很多公司工作过，我倾向于看到两种类型的系统。

最初由DBA创建的系统。它们通常有大量的SQL Agent作业、带有case语句、循环和业务逻辑、SSIS包等的大型链式机

最初由程序员创建的系统。它们通常没有索引或键、xml列等，DB仅用于对象的持久性。

DBA创建的系统崩溃是因为它们不扩展

程序员系统会得到损坏的数据，但仍在苦苦挣扎。因为您总是可以添加另一个web框。

根据Ewan的答复，我可以提出一种不用CLR来完成您的工作的方法：

1)创建作业(windows服务、计划任务运行的应用程序等)检查是否需要额外的数据。

2)通过调用Web.API从作业中获取数据

3)在工作中做好你的处理。如果逻辑是复杂的，C#比SQL要好得多。

4)保存工作中的数据。为了获得更好的性能，可以使用BulkInsert实现持久性。

像C++、C#、Java这样的高级语言几乎总是更适合用于定义业务逻辑。它们在迭代情况下执行得更好，允许OOP，高级日志记录，异常管理，调试等。

如果迁移存储过程不是一个选项，则仍然可以完成您的工作：

3)将获取的数据持久化到具有处理会话标识符的缓冲表中。如果获取的数据量很大，则批量插入是您的朋友。

4)使用处理会话标识符调用过程。该过程将从缓冲表中获取数据。

5)如果数据量很大，则可以在低使用率期间清空(截断)缓冲表，因为删除对性能有很大影响。