业务层VS的SQL Server

我有一个不复杂的计算会员的申请。每个成员可以有多个美国国家链接到他们的个人资料。每个成员完成的每个课程都有不同的计算。业务层VS的SQL Server

截至目前我已经数据库（SQL Server 2008中）中已进行计算，然后将数据发送回应用层，在那里他们可以看到他们的历史，然后下载为每门课程的证书。

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

2012-01-24 mick

我总是会在数据库中进行计算，如果**您的计算需要返回**大量数据**到中间层，计算一个“SUM”。为什么麻烦发送所有的数据？这个数据库能够很好地总结出一些数值，然后发回一个结果 - **效率更高**！所以，无论何时你需要做很多事情 - 但回报很少 - 在服务器上执行。 –

我同意@marc_s SQL Server旨在更快更高效地处理数据。 –

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

做了很多总结，计数，平均等数据，只返回一个值。将大量数据传输到中间层并没有意义，只是总结了一列
做了很多基于行/集的操作;如果您需要复制，插入和更新大量数据，那么将所有数据拖放到中间层然后将其全部发送回服务器实际上没有意义 - 在服务器上就可以随时进行。另外：T-SQL是显著快于基于集合的操作处理（如周围洗牌数据）比你的中间层东西可能是

简单：尽量避免发送大量数据到客户端/中间层/业务层，除非你绝对必须的（例如，因为你要下载存储在数据库中的文件，或者如果你真的需要有那些200行物化为对象在您的应用程序在什么地方显示或操作上）

一个常被忽视的功能是计算列正好在您的数据库表中 - 那些非常擅长于总结您的订单总额加上税金和运费总额，或者他们很好地将您的姓和名放在显示名称中。这些事情不应该仅在业务逻辑层中处理 - 如果直接在数据库中执行这些操作，那么当您检查数据库表并查看SQL Server中的数据时，也可以使用这些“计算”值MGMT工作室...

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

，如果它需要大量的逻辑检查，字符串分析，模式匹配等; T-SQL吸那些东西
，如果它需要的东西像调用Web服务来获取一些数据来验证你的数据，或者类似的东西
，如果它需要更多的商业逻辑运算（而不是严格的“原子”的数据库操作）

但这些只是“粗”的指导方针 - 它总是对每一种情况下设计的决定，我不严格的规则信;你的里程可能会有所不同，从案例到案例 - 所以选择一个最适合任何特定任务的方法。

来源

2012-01-24 21:42:37

它有助于在数据库内部没有业务逻辑代码（存储过程）。将它直接放在应用程序中更好，因此它适合于架构。此SQL代码包含您的业务逻辑，并且没有任何问题。（虽然数据或维护相关的代码在sprocs中没有问题）。

如果你的业务逻辑层没有做多少，是刚刚从SQL Server传递数据给调用者，也许你并不需要它。

来源

2012-01-24 21:48:31 usr

存储过程可以非常有用 - 只要它们处理数据库操作并且不“隐藏”业务逻辑即可。但是对于很多操作，使用存储过程可能非常有用。我不会仅仅在全球范围内“禁止”他们 –

你是对的。我在编辑这个。 – usr

谢谢你们，基本上，一旦我捕获数据，以出席什么当然，我发回的报告，为他们与连同其所有学分注册的每个状态的成员。我相信数据库是执行这些计算的正确位置。这是一个纯粹的vb.net/c#家伙，让我想知道我是否正确地做了这件事。当然，他坚持认为这一切都应该在BLL完成。每种情况都不一样。 – mick

业务逻辑层是不是有做繁重的，它的目的是提供一个抽象与主题的语言实体。因此，可以使用业务层为在该空间中工作所需的任何图层/应用程序提供共享且一致的方法。

要通过工程师的事情提出一个观点，最终目标将是业务逻辑层是整个组织用于该主题空间中工作的所有应用程序。即包裹在一个服务等

在小型应用程序来干这干那的现实世界中，商业逻辑层不觉得自己像一个附录一些时间。诀窍是还要记住任何用例都应该作为针对业务层的测试来实现，为您提供另一种方式来考虑它的公共接口应该是什么样子。

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

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

来源

2012-01-24 21:56:21 Nat

业务层VS的SQL Server

回答

相关问题