.net 当我们将主键传递给UI时，是否应该将其视为两层的混合和糟糕的做法？

当我们将任何对象的Db标识符传递给UI（比如url查询字符串中对象的PrimaryKey）时，我们基本上不是混合了两个层（Persistnet层和表示层）吗

在某种程度上，数据库标识符听起来像是与数据相关的持久层，但当我们“必须”在UI上传递它时，这不是一种糟糕的做法，我不知道有什么更好的做法

这是例外情况吗

---

简言之，多层体系结构如何解决这种做法，将持久层数据传递给UI？

这是一种每个人都必须处理的泄漏抽象

还有更多持久性泄漏到其他层的示例，例如验证域层中的字符串长度，因为数据库列中的长度设置为某个值。另一个例子可能是将EF IQueryable从DAL公开到域层，因为这样做会导致潜在数据库方案泄漏到域层

因此，我认为我们可以处理一个可接受的折衷方案，我们根本无法消除泄漏的抽象，但我们应该努力将其降至最低。将ID公开给UI是我处理的一个可以接受的折衷方案，因为它很简单，每个人都理解它

---

但是如果有人有一个银弹，我会很高兴听到：）

应用程序用户需要标识符，以便她能够正确识别数据库中的数据并与之交互。在解决方案的所有层中公开相同的标识符并没有什么坏处。没有他们，很难做任何有用的事情

---

我想您真正谈论的是代理键，而不是标识符或“主键”。问题是，为什么您首先需要创建这样一个密钥？原则上，代理键是将表示层从数据层抽象出来的糟糕方法，因为它们会造成您所描述的那种困境。人们以这种方式使用它们的原因通常是：SQL对键的支持较差，并且普遍缺乏数据独立性；行业不良行为的遗留；开发工具不足。

+1很好的解释。身份证是很自然的事情。每当您想要识别一个对象时，特别需要某种类型的标识符。为演示文稿使用不同的id是过分的。所以，将持久id以只读方式公开给表示层几乎不是一个坏做法。但是，从表示层设置持久性id是一种不好的做法。尽管如此，仅仅因为一个项具有唯一的id并不意味着该id必须来自数据库或由持久性层生成。