オブジェクトのDb識別子をUIに渡す場合（たとえば、URLクエリ文字列内のオブジェクトのPrimaryKey）、基本的に2つのレイヤー（Persistnetレイヤーとプレゼンテーションレイヤー）を混合していませんか？
データベース識別子は、ある意味で私だけに永続的なレイヤー関連データのように聞こえますが、それをUIに渡さなければならない場合、それは一種の悪い習慣ではありません。しかし、より良いもの。
例外的な場合ですか？
要するに、多層アーキテクチャはこの慣行にどのように対処し、永続的なレイヤーデータをUIに渡しますか？
これは、誰もが対処しなければならない一種のリーク抽象化です。
データベース列の長さが何らかの値に設定されているため、ドメイン層の文字列の長さを検証するなど、他の層に永続性がリークする例は他にもあります。別の例として、EF IQueryableをDALからドメインレイヤーに公開することが考えられます。これを行うと、潜在的なデータベーススキームがドメインレイヤーにリークするためです。
ですから、私たちが対処できる許容できる妥協点があり、漏れのある抽象化を完全に排除することはできないと思いますが、少なくともそれを実現するために一生懸命努力する必要があります。IDをUIに公開することは、単純で誰もが理解できるため、私が対処する妥協案として受け入れられます。
しかし、誰かが銀の弾丸を持っているなら、私は聞いてうれしいです:)
アプリケーションユーザーは、データベース内のデータを正しく識別して操作できるように、識別子が必要です。ソリューションのすべてのレイヤーで同じ識別子を公開することは悪いことではありません。それらなしで何か有用なことを成し遂げることは難しいでしょう。
一般的に、識別子や「主キー」ではなく、代理キーについて実際に話していると思います。問題は、そもそもなぜそのようなキーを作成する必要があったのかということです。原則として、代理キーは、説明している種類のジレンマを作成するため、データ層からプレゼンテーション層を抽象化するためのひどい方法です。人々がそれらをそのように使用しているという事実は、通常、次の理由によるものです。SQLのキーのサポートが不十分であり、データの独立性が一般的に欠如している。業界の悪い慣行の遺産。不十分な開発ツール。