mic*_*ick 6 vb.net sql-server business-logic-layer data-access-layer
我有一个应用程序,可以对成员进行复杂的计算.每个成员可以将多个美国州与其个人资料相关联.每个州对会员完成的每门课程都有不同的计算方法.
截至目前,我一直在数据库(SQL Server 2008)中执行计算,然后将数据发送回应用程序层,在那里他们可以看到他们的历史记录,然后为每个课程下载证书.
我有一个业务逻辑层,但不是很多.我知道这已被问了很多,但你认为我应该在哪里进行这些计算:业务层或数据库？我要来回走!!
我基本上会在SQL Server中做任何事情:
对数据进行大量求和,计数,求平均等,并仅返回单个值.将大量数据传输到中间层真的没有意义,只是为了总结一个列
做了很多基于行/集的操作; 如果你需要复制,插入,更新大量数据,那么将所有数据拖到中间层然后将它们全部发送回服务器真的没有意义 - 直接从服务器上执行此操作.另外:T-SQL在处理基于集合的操作(如洗牌数据)方面明显快于中间层中的任何操作
简而言之:尽量避免将大量数据发送到客户端/中间层/业务层,除非您必须(例如,因为您要下载存储在数据库中的文件,或者您确实需要拥有这200行)物化到您的应用程序中的对象,以显示在某处或在其上运行)
一个经常被忽略的功能是数据库表中的计算列 - 这些列表非常擅长,例如总结您的订单总额加税和运费到总计,或者他们很高兴将您的名字和姓氏组合成一个显示名称.实际上不应该只在业务逻辑层中处理这类事情 - 如果直接在数据库中执行这些操作,那么当您检查数据库表并查看SQL Server中的数据时,这些"计算"值也可用.管理工作室......
我会把它放到中间层/业务逻辑层
如果它需要广泛的逻辑检查,字符串解析,模式匹配等等; T-SQL很糟糕
如果它需要调用Web服务来获取一些数据以验证您的数据,或类似的东西
如果它需要更多的业务逻辑操作(而不是严格的"原子"数据库操作)
但这些只是"粗略"的指导方针 - 它始终是每个案例的设计决策,我不相信严格的规则; 根据具体情况,您的里程可能会有所不同 - 因此,选择一种最适合任何特定任务的方法.
| 归档时间： |
|
| 查看次数： |
568 次 |
| 最近记录： |