当我们将任何对象的 Db 标识符传递给 UI 时（假设是 url 查询字符串中对象的 PrimaryKey），我们不是基本上混合了两个层（Persistnet 层和表示层）吗？
数据库标识符在某种程度上听起来像是与持久层相关的数据，但是当我们“必须”在 UI 上传递它时，这不是一种不好的做法，我不知道什么可能是不过更好的一个。
是不是特殊情况？
简而言之，多层架构如何解决这种做法，将持久层数据传递给 UI？
问问题
288 次
2 回答
3
这是一种每个人都必须处理的泄漏抽象。
还有更多持久性泄漏到其他层的示例，例如验证域层中的字符串长度，因为数据库列中的长度设置为某个值。另一个示例可能是将 DAL 中的 EF IQueryable 暴露给域层，因为这样做会使潜在的数据库方案泄漏到域层。
所以我认为我们可以处理一个可接受的折衷方案，我们根本无法消除泄漏抽象，但我们应该努力至少做到这一点。将 ID 暴露给 UI 是我处理的一种可接受的折衷方案，因为它很简单并且每个人都理解它。
但如果有人有灵丹妙药，我会很高兴听到:)
于 2011-06-20T11:49:27.330 回答
1
应用程序用户需要标识符，以便她可以正确识别数据库中的数据并与之交互。在解决方案的所有层中公开相同的标识符并没有什么不好。没有它们就很难完成任何有用的事情。
我希望您实际上是在谈论代理键，而不是一般的标识符或“主键”。问题是，为什么您首先需要创建这样的密钥？原则上，代理键是从数据层中抽象出表示层的糟糕方法，因为它们会造成您所描述的那种困境。人们以这种方式使用它们的事实通常是由于： SQL 对键的支持很差，并且普遍缺乏数据独立性；行业不良做法的遗留问题；开发工具不足。
于 2011-06-20T12:42:37.210 回答