业务规则应该在应用程序层和数据库层中强制执行，还是仅在两者之一中强制执行？
我一直在我的应用程序层（模型）和数据库层（引发错误的存储过程）中强制执行业务规则。
几个原因，我一直在这两个地方重复我的验证：
- 由于以下 当他们被检查时 应用程序代码以及它们何时 在数据库中查了一下， 数据库中的业务规则检查 将会扭转局面。数据库 还允许我锁定各种 比在更简单的方式记录 我的应用程序代码，看起来 自然要在这里这样做。
- 如果我们有 做一些批量数据 如果我路由，则直接插入/更新数据库 所有这些操作都通过我的 存储过程/函数 正在执行业务规则 验证，我没有机会 即使我缺乏通过应用程序进行单输入时所获得的保护，也会输入错误的数据。
- 尽管 仅在 数据库也会有同样的效果 从实际数据看来 仅仅将数据扔到 数据库先制作好 努力验证它是否符合 约束和业务规则。
什么是正确的平衡？
I have been enforcing business rules in both my application tier (models) and my database tier (stored procedures who raise errors).
I've been duplicating my validations in both places for a few reasons:
- If the conditions change between
when they are checked in the
application code and when they are
checked in the database, the
business rule checks in the database
will save the day. The database
also allows me to lock various
records in a simpler manner than in
my application code, so it seems
natural to do so here. - If we have
to do some batch data
insertions/updates to the database directly, if I route
all these operations through my
stored procedures/functions which
are doing the business rule
validations, there's no chance of me
putting in bad data even though I lack the protections that I would get if I was doing single-input through the application. - While
enforcing these things ONLY in the
database would have the same effect
on the actual data, it seems
improper to just throw data at the
database before first making a good
effort to validate that it conforms
to constraints and business rules.
What's the right balance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您需要在数据层强制执行以确保数据完整性。这是你的最后一道防线，也是数据库的工作，帮助强化其数据世界观。
也就是说，将垃圾数据扔到数据库中进行验证是一种粗略的技术。通常，错误被设计为人类可读而不是机器可读，因此程序处理来自数据库的错误并从中找出正面或反面的效率很低。
存储过程是另一回事。过去，存储过程是处理数据层等业务规则的方式。
但今天，随着现代应用程序服务器环境的发展，它们通常已成为放置此逻辑的更好位置。它们提供多种访问和公开数据的方式（Web、Web 服务、远程协议、API 等）。此外，如果您的规则占用大量 CPU（可以说大多数都不是），那么扩展应用程序服务器比扩展数据库服务器更容易。
应用程序服务器中的大量功能赋予它们超出数据库服务器所能做到的灵活性，因此，许多曾经推回数据库的内容正在被撤出，数据库服务器被降级为“哑持久性”。
也就是说，使用存储过程等肯定有性能优势，但现在这是一个调整问题，问题变成“为了通过将其放入数据库服务器而获得的收益是否值得失去应用程序服务器功能”。
对于应用程序服务器，我所说的不仅仅是 Java，还有 .NET 甚至 PHP 等。
You need to enforce at the data tier to ensure data integrity. That's your last line of defense, and that's the DBs job, to help enforce its world view of the data.
That said, throwing junk data against the DB for validation is a coarse technique. Typically the errors are designed to be human readable rather than machine readable, so its inefficient for the program to process the error from the DB and make heads or tails out of it.
Stored Procedures are a different matter. Back in the day, Stored Procedures were The Way to handle business rules on the data tiers, etc.
But today, with the modern application server environments, they have become a, in general, better place to put this logic. They offer multiple ways to access and expose the data (the web, web services, remote protocols, APIs, etc). Also, if your rules are CPU heavy (arguably most aren't) it's easier to scale app servers than DB servers.
The large array of features within the app servers give them a flexibility beyond what the DB servers can do, and thus much of what was once pushed back in to the DBs is being pulled out with the DB servers being relegated to "dumb persistence".
That said, there are certainly performance advantages using Stored Procs and such, but now that's a tuning thing where the question becomes "is it worth losing the app server capability for the gain we get by putting it in to the DB server".
And by app server, I'm not simply talking Java, but .NET and even PHP etc.
如果规则必须始终执行，无论数据来自何处或如何更新，那么数据库就是它需要的地方。请记住，直接查询会影响数据库进行影响许多记录的更改或执行应用程序通常不会执行的操作。这些事情比如当一个客户被另一个客户买断时修复一组记录，他们想要更改所有历史数据，对尚未处理的订单应用新的税率，修复一些错误的数据输入。它们有时也会受到不使用您的数据层的其他应用程序的影响。它们还可能受到通过 ETL 程序运行的导入的影响，这些程序也无法使用您的数据层。因此，如果在所有情况下都必须遵守该规则，则它必须存在于数据库中。
如果规则仅适用于有关此特定输入页面如何工作的特殊情况，则它需要位于应用程序中。因此，如果销售经理只能通过用户界面执行特定操作，则可以在应用程序中指定这些操作。
在这两个地方做一些事情是有帮助的。例如，允许用户在与日期字段相关的输入框中输入非日期是愚蠢的。数据库中的数据类型仍然应该是日期时间数据类型，但最好在发送之前检查其中的一些内容。
If the rule must be enforced at all times no matter where the data came from or how it was updated, the database is where it needs to be. Remember databases are affected by direct querying to make changes that affect many records or to do something the application would not normally do. These are things like fixing a group of records when a customer is bought out by another customer and they want to change all the historical data, the application of new tax rates to orders not yet processed, the fixing of a some bad data inputs. They are also affected sometimes by other applications which do not use your data layer. They may also be affected by imports run through ETL programs which also cannot use your data layer. So if the rule must in all cases be followed, it must be in the database.
If the rule is only for special cases concerning how this particular input page works, then it needs to be in the application. So if a sales manager has only specific things he can do from his user interface, these things can be specified in the application.
Somethings it is helpful to do in both places. For instance, it is silly to allow a user to put a non-date in an input box that will relate to a date field. The datatype in the database should still be a datetime datatype, but it is best to check some of this stuff before you send.
您的业务逻辑可以位于任一位置，但不应同时位于两个位置。逻辑不应该重复，因为试图保持两者同步很容易犯错误。如果将其放入模型中，您将希望所有数据访问都通过您的模型，包括批量更新。
将其放入数据库与应用程序模型中需要权衡（以下是我的一些想法）：
Your business logic can sit in either location, but should not be in both. The logic should NOT be duplicated because it's easy to make a mistake trying to keep both in sync. If you put it in the model you'll want all data access to go through your models, including batch updates.
There will be trade-offs to putting it in the database vs the application models (here's a few of the top of my head):