当我们将主键传递给 UI 时，是否应该将其视为 2 层的混合和糟糕的做法？
当我们将任何对象的 Db 标识符传递给 UI 时（假设 url 查询字符串中对象的 PrimaryKey），我们基本上不是混合了两层（Persistnet 层和表示层）吗？
数据库标识符在某种程度上听起来像是与数据相关的持久层，但是当我们“必须”在 UI 上传递它时，这并不是一种糟糕的做法，我不知道什么可能是不过更好的一个。
是不是属于特殊情况？
简而言之，多层架构如何解决这种实践，将持久层数据传递给 UI？
When we pass a Db identifier of any object to the UI (Let's say the PrimaryKey of an object in the url query string) aren't we mixing two layers (Persistnet layer and presentation layer) basically?
A data-base identifier sounds like a persistent layer related data only to me in a way, but when we 'have' to pass it on UI, isn't is a kind of BAD practice, where I have no idea what could be a better one though.
Is it in an exceptional case?
In short, how does the multi-tier architecture addresses this practice, passing a persistent layer data to UI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是每个人都必须处理的一种泄漏抽象。
还有更多持久性泄漏到其他层的示例，例如验证域层中的字符串长度，因为数据库列中的长度设置为某个值。另一个示例可能是将 EF IQueryable 从 DAL 暴露到域层，因为这样做潜在的数据库方案会泄漏到域层。
所以我认为我们可以处理一个可接受的妥协，我们根本无法消除泄漏抽象，但我们应该努力至少实现它。将 ID 暴露给 UI 是我可以接受的妥协方案，因为它很简单并且每个人都理解它。
但如果有人有灵丹妙药，我会很高兴听到:)
It's a kind of a Leaky Abstraction everybody has to deal with.
There is more examples of persistance leaking to other layers as for example validating string lenght in domain layer because the lenght in the database column is set to some value. Another example could be exposing EF IQueryable from DAL to domain layer, because doing that the potenital database scheme is leaking to the domain layer.
So I think there is a acceptable compromise we could deal with and we can't eliminate leaky abstraction at all but we should work hard to have it at minimum. Exposing the ID to UI is a such acceptable compromise I deal with because it's simple and everybody understand it.
But if someone has a silver bullet I will be glad to hear about :)
应用程序用户需要标识符，以便她可以正确识别数据库中的数据并与之交互。在解决方案的所有层中公开相同的标识符并没有什么坏处。没有他们，就很难完成任何有用的事情。
我希望您真正谈论的是代理键，而不是一般的标识符或“主键”。问题是，为什么首先需要创建这样一个密钥？原则上，代理键是将表示层从数据层中抽象出来的糟糕方法，因为它们会造成您所描述的那种困境。人们以这种方式使用它们的事实通常是由于： SQL 对键的支持很差并且普遍缺乏数据独立性；行业不良做法的遗留问题；开发工具不足。
The application user needs identifiers so she can correctly identify and interact with the data in the database. There's nothing bad about exposing the same identifiers in all layers of your solution. It would be hard to get anything useful done without them.
I expect you are really talking about surrogate keys rather than identifiers or "primary keys" in general. The question is, why did you need to create such a key in the first place? In principle, surrogate keys are lousy way to abstract your presentation tier from the data tier precisely because they create the sort of dilemma you are describing. The fact that people use them that way is usually due to: SQL's poor support for keys and general lack of data independence; a legacy of industry bad practices; inadequate development tools.