我有一个应用程序可以对成员进行复杂的计算。每个成员可以将多个美国州与其个人资料相关联。每个州对会员完成的每门课程都有不同的计算方法。
截至目前，我一直在数据库（SQL Server 2008）中执行计算，然后将数据发送回应用层，在那里他们可以查看自己的历史记录，然后为每个课程下载证书。
我有一个业务逻辑层，但不是很多。我知道这已被问了很多，但你认为我应该在哪里进行这些计算：业务层或数据库？我来回走动!!
答案 0 :(得分：6)
我基本上会在SQL Server中做任何事情：
对数据进行大量求和，计数，求平均等，并且只返回一个值。 将大量数据传输到中间层真的没有意义，只是为了总结一列
做了很多基于行/集的操作;如果你需要复制，插入，更新大量数据，那么将所有数据拖到中间层然后将它们全部发送回服务器真的没有意义 - 直接从服务器上执行此操作。另外：T-SQL在处理基于集合的操作（如洗牌数据）方面明显快于中间层中的任何操作
简而言之：尽量避免将大量数据发送到客户端/中间层/业务层，除非您必须（例如，因为您要下载存储在数据库中的文件，或者您真的需要将这200行实体化为您应用中的对象，以便在某处显示或进行操作）
经常被忽视的一个功能是数据库表中的计算列 - 这些功能非常擅长于总结您的订单总额加税和运费到总计，或者他们很高兴将您的名字和姓氏放在显示名称中。实际上不应该只在业务逻辑层中处理这类事情 - 如果直接在数据库中执行这些操作，那么当您检查数据库表并查看SQL Server中的数据时，这些“计算”值也可用。管理工作室......
我会把它放到中间层/业务逻辑层
如果它需要广泛的逻辑检查，字符串解析，模式匹配等等; T-SQL很糟糕
如果它需要调用Web服务来获取一些数据以验证您的数据，或类似的东西
如果它需要更多的业务逻辑操作（而不是严格的“原子”数据库操作）
但那些只是“粗略”的指导方针 - 它总是每个案例的设计决定，我不相信严格的规则;根据具体情况，您的里程可能会有所不同 - 因此，选择一种最适合任何特定任务的方法。
答案 1 :(得分：0)
有助于在数据库（存储过程）中没有业务逻辑代码。将它直接放在应用程序中会更好，因此它适合于体系结构。此SQL代码包含您的业务逻辑，并且没有任何问题。 （尽管在sprocs中使用数据或维护相关代码没有任何问题。）
如果您的业务逻辑层没有做太多工作并且只是将数据从SQL Server传递给调用者，那么您可能根本不需要它。
答案 2 :(得分：0)
业务逻辑层不是要做繁重的工作，它的目的是提供与主题语言中的实体的抽象。因此，业务层可用于为在该空间中工作所需的任何层/应用程序提供共享和一致的方法。
为了过度设计要点，最终目标是在整个组织中使用业务逻辑层，以便在该主题空间中工作的所有应用程序。即包裹在服务等。
在这个或那个小应用程序的现实世界中，业务逻辑层确实感觉像是一个附录。诀窍是还要记住，任何用例都应该作为业务层的测试来实现，为您提供另一种思考公共接口应该如何看待的方法。
业务逻辑层如何完成工作应该隐藏在调用它的应用程序的那些部分。
因此，只要在业务逻辑层中给出适当的表示，就可以以最有效的方式（即sql）计算数据。