软件设计——三层架构
第 3 层 - 界面
第 2 层 - 业务逻辑（获取用户输入，检查是否有效，发送到数据库功能）
第 1 层 - 数据库（创建、更新、获取记录等）
用户可以添加多个联系电话号码（如果是）添加的第一个电话号码系统会自动将该电话号码设置为主要电话号码，之后用户可以自行更改其主要电话号码。
当数据库中创建第一条电话号码记录时，哪一层负责检查该电话号码是否需要设置为主要号码？
Layer 3 - Interface
Layer 2 - Business logic (get input from user, check if valid, send to database function)
Layer 1 - Database (creates, updates, gets records etc)
A user can add many contact phone numbers, if it is the first phone number added the system will automatically set that phone number to primary, and there after the user can change his primary phone number on his own.
When the first phone number record is created in the database, which layer is responsible to check if the phone number needs to be set to primary or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
业务层。数据库应该存储数据，而不是做出决策。界面只是与用户交互。业务层制定规则。
Business layer. The database should be storing data, not making decisions. The interface just interacts with the user. The business layer makes the rules.
当电话号码添加到用户时，您的业务逻辑应该处理它。您可以通过为其提供单元/集成测试来验证它是否有效。
Your business logic should handle it when the phone number gets added to the user. You can verify it works by providing unit/integration tests for it.
我想这取决于你的目标是什么。因为它是您的业务层应该处理被验证/设置为主要的电话。我认为数据库仍然需要以某种方式存储这些信息。
然而，在某些情况下，例如安全验证，您需要在接口、逻辑和数据库级别进行一些检查。是的，这是多余的，但我认为您需要保证破坏您的界面或逻辑的黑客无法四处乱搞您的基础数据。
I guess it depends what you're aiming for. As it is your business layer should handle phone being validated/set as primary. Database would still need to store that information in some way I think.
However in certain cases like security verification you'll need to do some checks at Interface, Logic and Database level. Yes it is redundant but I think you'll want to guarantee that hackers that break your interface or logic, can't go around messing with your underlying data.
N 层应用程序中的数据层实际上不应该做任何事情，除了放入值和获取值之外。将其视为持久性服务。
除了 UI 代码之外，其他所有内容都进入所谓的业务和/或逻辑层（您应该在遵循 MVP、MVC 或 MVVM 等内容时将这些内容分开）。
虽然这个简单的问题实际上引发了事务问题，但您的数据模型最终应该防止这种情况发生，但如果您无法作为原子单元完成操作，则总是有可能同时输入两个电话号码，并且它们最终都会成为主要（取决于应用程序和数据库之间的延迟）。为了优雅地处理这些情况，您至少需要考虑以有意义的方式传播这些问题的错误恢复（错误处理）。不要只是让你的应用程序崩溃。
The data layer in an N-tier application isn't really supposed to do anything other than to put values in and get values in. Think of it as an persistence service.
Everything else goes into what's known as the business and/or logic layer except for UI code (you're supposed to keep those things separate in following something like MVP, MVC or MVVM).
Though this simple problem actually raises a issue with transactions, your data model should eventually prevent this, but if you cannot complete the operation as an atomic unit there always the chance that two phone numbers are put at the same time and they both end up as primary (depending on the latency between the application and database). To gracefully handling these situations you need at least think about error recovery (error handling) that propagates these problems in a meaningful manner. Don't just crash your application.
只是为了添加上述答案，您可能需要考虑保留输入，而不管有效性如何。可以添加更多的开发（特别是如果您需要清理数据），但根据您的应用程序，这是值得的
Just to add to the above answers, you might want to consider persisting input regardless of validity. Can add a bit more development (especially if you need to clean the data) but it can be worth it depending on your application