业务层与 SQL Server
我有一个为成员进行复杂计算的应用程序。每个成员可以将多个美国州链接到他们的个人资料。每个州对会员完成的每门课程都有不同的计算。
截至目前，我一直在数据库（SQL Server 2008）中执行计算，然后将数据发送回应用程序层，他们可以在其中查看其历史记录，然后下载每门课程的证书。
我有一个业务逻辑层，但那里没有发生太多事情。我知道这个问题已经被问了很多，但是您认为我应该在哪里执行这些计算：业务层还是数据库？我要来来回回！！
I have an application that does complex calculations for members. Each member can have multiple US states linked to their profile. Each state has got different calculations for each course a member completes.
As of now I have been performing the calculations in the DB (SQL Server 2008) and then sending data back to app layer where they can see their history and then download a certificate for each course.
I have a business logic layer but not a lot happens there. I know this has been asked a lot but where do you think I should perform these calculations: business layer or database? I am going back and forth!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我基本上会在 SQL Server 中执行以下操作：
对数据进行大量求和、计数、求平均值等操作，并且仅返回单个值。
将大量数据传输到中间层确实没有意义，只是为了汇总一列
做了很多基于行/集的操作；如果您需要复制、插入、更新大量数据，那么将所有数据拖到中间层然后将其全部发送回服务器确实没有意义 - 从一开始就在服务器上执行此操作。另外：T-SQL 在处理基于集合的操作（如随机排列数据）方面比中间层中的任何内容要快得多
简而言之：尽量避免将大量数据发送到客户端/中间层/业务层除非您绝对必须这样做（例如，因为您想要下载存储在数据库中的文件，或者您确实需要将这 200 行具体化为应用程序中的对象，以便在某处显示或进行操作）
经常被忽视的一项功能是数据库表中的计算列 - 这些非常擅长将您的订单总额加上税金和运费汇总为总计，或者它们非常适合将您的名字和姓氏放在一起显示姓名。这些事情确实不应该只在业务逻辑层中处理 - 如果您直接在数据库中执行这些操作，那么当您检查数据库表并查看 SQL Server 中的数据时，您也可以使用这些“计算”值Mgmt Studio ...
我会将其放入中间层/业务逻辑层
如果它需要调用 Web 服务来获取一些数据来验证数据，或者类似的事情
如果它需要更多的业务逻辑操作（而不是严格的“原子”数据库操作）
但这些只是“粗略”指导方针——这始终是针对每种情况的设计决策，我不相信严格的规则；您的情况可能因具体情况而异 - 因此请选择最适合手头特定任务的一种方法。
I would basically do anything in SQL Server that:
does a lot of summing, counting, averaging etc. of data and returns only a single value.
There's really no point in transferring large volumes of data to the middle tier, just to sum up a column
does a lot of row / set-based manipulation; if you need to copy, insert, update lots of data, again, there's really no point in dragging all that data to the middle tier and then sending it all back to the server - do it on the server right from the get go. Also: T-SQL is significantly faster in dealing with set-based operations (like shuffling data around) than anything in your middle tier could be
In brief: try to avoid sending large volumes of data to the client/middle-tier/business layer unless you absolutely have to (e.g. because you want to download a file stored in a database, or if you really need to have those 200 rows materialized into objects in your app to be displayed somewhere or operated on)
One feature that's often overlooked are computed columns right in your database table - those are really good at e.g. summing up your order total plus tax and shipping into a grand total, or they are great to put together your first and last name into a display name. Those kinds of things really shouldn't be handled only in the business logic layer - if you do those in the database directly, those "computed" values are also available to you when you inspect the database tables and look at the data in SQL Server Mgmt Studio ...
I would put it into the middle tier / business logic layer
if it required extensive logic checking, string parsing, pattern matching and so forth; T-SQL sucks at those things
if it required things like calling a web service to get some data to validate your data against, or something like that
if it required more of a business logic operation (rather than strict "atomic" database operations)
But those are just "rough" guidelines - it's always a design decision for each case, and I don't believe in strict rules; your mileage may vary, from case to case - so pick the one approach that works best for any given task at hand.
它有助于不在数据库内部包含业务逻辑代码（存储过程）。最好将其直接放在应用程序中，这样它就适合架构。这段SQL代码包含了你的业务逻辑，没有任何问题。 （不过，在存储过程中包含数据或维护相关代码并没有什么问题）。
如果您的业务逻辑层没有做太多事情，只是将数据从 SQL Server 传递到调用者，也许您根本不需要它。
It helps to not have business logic code inside of the database (stored procedures). It is much better to have it directly in the application so it fits right in the architecture. This SQL code contains your business logic and there is nothing wrong with it. (There is nothing wrong with having data or maintenance related code in sprocs though).
If your business logic layer is not doing much and is just passing the data from SQL Server to the caller, maybe you don't need it at all.
业务逻辑层并不承担繁重的工作，它的目的是提供主题语言中实体的抽象。因此，业务层可用于为在该空间中工作所需的任何层/应用程序提供共享且一致的方法。
为了通过过度设计来表达观点，最终目标是业务逻辑层在整个组织中用于该主题空间中工作的所有应用程序。即包裹在服务等中。
在现实世界中，小型应用程序要做这或那，业务逻辑层有时确实感觉像一个附录。诀窍是还要记住，任何用例都应该作为针对业务层的测试来实现，从而为您提供另一种方式来思考其公共接口应该是什么样子。
业务逻辑层如何完成其工作应该对调用它的应用程序部分隐藏。
因此，以最有效的方式（即sql）计算数据是完全可以接受的，只要这些计算在业务逻辑层中给出适当的表示即可。
The business logic layer is not there to do the heavy lifting, it's purpose is to provide an abstraction with entities in the language of the subject matter. Thus the business layer can be used to provide as shared and consistent approach across for any layers/applications that are required to work in that space.
To over engineer things to make a point, the ultimate goal would be that the business logic layer is used across an organisation for all applications working in that subject space. I.e. wrapped in a service etc.
In the real world of small apps to do this or that, the business logic layer does feel like an appendix some times. The trick is to also remember that any uses cases should be implemented as tests against the business layer, giving you another way to think of how it's public interface should look.
How the business logic layer gets it's work done should be hidden from those parts of the application calling it.
Thus it is perfectly acceptable to calculate the data in the most efficient manner (i.e. sql), so long as these calculations are given an appropriate representation in the business logic layer.